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  (Amit Kapila <amit.kapila16@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] wait events for disk I/O
Следующее
От: Michael Paquier
Дата:
Сообщение: [HACKERS] Implementation of SASLprep for SCRAM-SHA-256