You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have a table and we run pg_repack on it. We noticed that the access to the table occurs through SeqScan. And the COPY command uses Parallel SeqScan. The table goes through pg_repack in 45 minutes, and if you copy it using COPY, then in 15. Is there an opportunity to add Parallel SeqScan to pg_repack? And if not, why?
The text was updated successfully, but these errors were encountered:
I'm not keen on reinventing insert .. select in pg_repack. In the postgresql core, the implementation of parallel INSERT SELECT has a long history, once it was even committed, but then reverted.
#251 will helps is some cases (probably in most cases). I forgot about this patch, to be honest.
We have a table and we run pg_repack on it. We noticed that the access to the table occurs through SeqScan. And the COPY command uses Parallel SeqScan. The table goes through pg_repack in 45 minutes, and if you copy it using COPY, then in 15. Is there an opportunity to add Parallel SeqScan to pg_repack? And if not, why?
The text was updated successfully, but these errors were encountered: