Re: [HACKERS] Parallel seq. plan is not coming against inheritance orpartition table
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] Parallel seq. plan is not coming against inheritance orpartition table |
Дата | |
Msg-id | CA+TgmoasxJkY5oUrTfn9SHiKXFON16E3iWKf86jAZDsvfrn0Bw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Parallel seq. plan is not coming against inheritance orpartition table (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: [HACKERS] Parallel seq. plan is not coming against inheritance orpartition table
|
Список | 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 по дате отправления: