On 11/23/15 5:47 PM, Robert Haas wrote:
2. In Parallel Seq Scan, the determination of what page to scan next isn't dependent on the contents of any page previously scanned. In Parallel Index Scan, it is. Therefore, the amount of effective parallelism is likely to be less. This doesn't mean that trying to parallelize things here is worthless: one backend can be fetching the next index page while some other backend is processing the tuples from a page previously read.
Presumably we could simulate that today by asking the kernel for the next page in advance, like we do for seqscans when effective_io_concurrency > 1. My guess is a parallel worker won't help there.
Where a parallel worker might provide a lot of benefit is separating index scanning from heap scanning (to check visibility or satisfy a filter). It wouldn't surprise me if a single worker reading an index could keep a number of children busy retrieving heap tuples and processing them. It might be nice if an index scan node just fired up it's own workers and talked to them directly.
-- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
