Re: [HACKERS] Parallel seq. plan is not coming against inheritance orpartition table - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] Parallel seq. plan is not coming against inheritance orpartition table
Date
Msg-id CA+TgmoasxJkY5oUrTfn9SHiKXFON16E3iWKf86jAZDsvfrn0Bw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Parallel seq. plan is not coming against inheritance orpartition table  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: [HACKERS] Parallel seq. plan is not coming against inheritance orpartition table  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Tue, Mar 7, 2017 at 9:24 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> If we have lesser index pages and more heap pages, then we limit the
> parallelism based on index pages.

Kinda.  In most cases, we figure out the degree of parallelism based
on heap pages and then we figure out the degree of parallelism based
on index pages and we return the smaller of those numbers.  However,
as an exception, if one of those numbers would be zero and the other
would be non-zero, then we return 1 instead of 0.  That's randomly
inconsistent, and I think it's a bug which my proposed patch would
fix.  I don't understand how you can justify returning the smaller of
the two values in every other case, but in that case return something
else.

> I think it can give us benefit in
> such cases as well (especially when we have to discard rows based heap
> rows).  Now, consider it from another viewpoint, what if there are
> enough index pages (> min_parallel_index_scan_size) but not sufficient
> heap pages.  I think in such cases parallel index (only) scans will be
> beneficial especially because in the parallel index only scans
> heap_pages could be very less or possibly could be zero.

That's a separate problem.  I think we ought to consider having an
index-only scan pass -1 for the number of heap pages, so that the
degree of parallelism in that case is limited only by the number of
index pages.  I was going to bring up that issue after I got this
committed.  :-)

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] wait events for disk I/O
Next
From: Michael Paquier
Date:
Subject: [HACKERS] Implementation of SASLprep for SCRAM-SHA-256