On Mon, Nov 23, 2015 at 5:38 PM, David Fetter <da...@fetter.org> wrote: > That sounds like a very handy thing to have. Any idea whether it's > possible for 9.6? Is there any of the Parallel Seq Scan code that > looks like it could be reused or slightly generalized for the > implementation?
I think it would be a good idea to pattern a hypothetical Parallel Index Scan feature after what we did in commits ee7ca559fcf404f9a3bd99da85c8f4ea9fbc2e92 and f0661c4e8c44c0ec7acd4ea7c82e85b265447398, which are only about 500 lines of code combined, but I don't expect any direct code reuse to be possible. However: 1. Parallel Seq Scan is easier because we have, at present, only one heapam API. Partial Index Scan is likely to be more complicated because we need to deal not only with the indexam API but also with the individual access methods (btree, etc.). 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. 3. Without Gather Merge, it figures to be mostly useless, because a straight Gather node is order-destroying. I'm not prepared to speculate on whether this will get done for 9.6 at this point. I'll say it would be nice. :-) -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers