From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, tushar <tushar(dot)ahuja(at)enterprisedb(dot)com> |
Subject: | Re: Parallel seq. plan is not coming against inheritance or partition table |
Date: | 2017-03-08 02:58:51 |
Message-ID: | CA+TgmoasxJkY5oUrTfn9SHiKXFON16E3iWKf86jAZDsvfrn0Bw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Mar 7, 2017 at 9:24 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-03-08 03:01:49 | Implementation of SASLprep for SCRAM-SHA-256 |
Previous Message | Robert Haas | 2017-03-08 02:53:37 | Re: wait events for disk I/O |