Re: [HACKERS] Parallel Plans and Cost of non-filter functions - Mailing list pgsql-hackers

From Paul Ramsey
Subject Re: [HACKERS] Parallel Plans and Cost of non-filter functions
Date
Msg-id CACowWR0NzuZoV2XuhY=w0ff=UJcPdVQq22NG=Q675y3_a9pxSQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Parallel Plans and Cost of non-filter functions  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: [HACKERS] Parallel Plans and Cost of non-filter functions  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
From my perspective, this is much much better. For sufficiently large tables, I get parallel behaviour without jimmying with the defaults on parallel_setup_cost and parallel_tuple_cost. *And*, the parallel behaviour *is* sensitive to the costs of functions in target lists, so reasonably chosen costs will flip us into a parallel mode for expensive functions against smaller tables too.
Hopefully some variant of this finds it's way into core! Is there any way I can productively help?
P.

On Sat, Nov 4, 2017 at 10:02 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
On Sat, Nov 4, 2017 at 4:43 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Paul Ramsey <pramsey@cleverelephant.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@mail.gmail.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.

[1] - https://www.postgresql.org/message-id/CAA4eK1%2B1H5Urm0_Wp-n5XszdLX1YXBqS_zW0f-vvWKwdh3eCJA%40mail.gmail.com

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Client Connection redirection support for PostgreSQL
Next
From: Raúl Marín Rodríguez
Date:
Subject: Re: [HACKERS] pow support for pgbench