On Tue, Jan 15, 2013 at 8:19 PM, Bruce Momjian <br...@momjian.us> wrote: >> Given our row-based storage architecture, I can't imagine we'd do >> anything other than take a row-based approach to this.. I would think >> we'd do two things: parallelize based on partitioning, and parallelize >> seqscan's across the individual heap files which are split on a per-1G >> boundary already. Perhaps we can generalize that and scale it based on >> the number of available processors and the size of the relation but I >> could see advantages in matching up with what the kernel thinks are >> independent files. > > The 1GB idea is interesting. I found in pg_upgrade that file copy would > just overwhelm the I/O channel, and that doing multiple copies on the > same device had no win, but those were pure I/O operations --- a > sequential scan might be enough of a mix of I/O and CPU that parallelism > might help.
AFAIR, synchroscans were introduced because multiple large sequential scans were counterproductive (big time). -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
