Re: Parallel Aggregate

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: Parallel Aggregate
Дата
Msg-id CAKJS1f_itLNeVB9uV4GYiBrRZxtpVVyqRSGjKgW+W3AsA1oH8w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Parallel Aggregate  (James Sewell <james.sewell@lisasoft.com>)
Список pgsql-hackers
On 15 March 2016 at 11:24, James Sewell <james.sewell@lisasoft.com> wrote:
> On Tuesday, 15 March 2016, Robert Haas <robertmhaas@gmail.com> wrote:
>>
>> > Does the cost of the aggregate function come into this calculation at
>> > all? In PostGIS land, much smaller numbers of rows can generate loads
>> > that would be effective to parallelize (worker time much >> than
>> > startup cost).
>>
>> Unfortunately, no - only the table size.  This is a problem, and needs
>> to be fixed.  However, it's probably not going to get fixed for 9.6.
>> :-(
>
>
> Any chance of getting a GUC (say min_parallel_degree) added to allow setting
> the initial value of parallel_degree, then changing the small relation check
> to also pass if parallel_degree > 1?
>
> That way you could set min_parallel_degree on a query by query basis if you
> are running aggregates which you know will take a lot of CPU.
>
> I suppose it wouldn't make much sense at all to set globally though, so it
> could just confuse matters.

I agree that it would be nice to have more influence on this decision,
but let's start a new thread for that. I don't want this one getting
bloated with debates on that. It's not code I'm planning on going
anywhere near for this patch.

I'll start a thread...

-- David Rowley                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Parallel Aggregate
Следующее
От: Kouhei Kaigai
Дата:
Сообщение: Re: Reworks of CustomScan serialization/deserialization