From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Paul Ramsey <pramsey(at)cleverelephant(dot)ca> |
Cc: | Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Parallel Plans and Cost of non-filter functions |
Date: | 2017-11-05 05:02:50 |
Message-ID: | CAA4eK1+wE0ywwwvLci1aFJzstVqhnpHmjXasN0YBvTCD_-gQWQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Nov 4, 2017 at 4:43 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Paul Ramsey <pramsey(at)cleverelephant(dot)ca> writes:
>>> Whether I get a parallel aggregate seems entirely determined by the number
>>> of rows, not the cost of preparing those rows.
>
>> This is true, as far as I can tell and unfortunate. Feeding tables with
>> 100ks of rows, I get parallel plans, feeding 10ks of rows, never do, no
>> matter how costly the work going on within. That's true of changing costs
>> on the subquery select list, and on the aggregate transfn.
>
> This sounds like it might be the same issue being discussed in
>
> https://www.postgresql.org/message-id/flat/CAMkU=1ycXNipvhWuweUVpKuyu6SpNjF=yHWu4c4US5JgVGxtZQ(at)mail(dot)gmail(dot)com
>
I have rebased the patch being discussed on that thread.
Paul, you might want to once check with the recent patch [1] posted on
the thread mentioned by Tom.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Connor Wolf | 2017-11-05 08:09:51 | Re: How to implement a SP-GiST index as a extension module? |
Previous Message | Amit Kapila | 2017-11-05 04:57:56 | Re: why not parallel seq scan for slow functions |