Re: [HACKERS] Parallel Plans and Cost of non-filter functions

On Mon, Nov 6, 2017 at 7:40 PM, Paul Ramsey wrote: > 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

Re: [HACKERS] Parallel Plans and Cost of non-filter functions

>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

Re: [HACKERS] Parallel Plans and Cost of non-filter functions

On Sat, Nov 4, 2017 at 10:02 PM, Amit Kapila wrote: > On Sat, Nov 4, 2017 at 4:43 AM, Tom Lane wrote: > > Paul Ramsey writes: > >>> Whether I get a parallel aggregate seems entirely determined by the > number > >>> of

Re: [HACKERS] Parallel Plans and Cost of non-filter functions

On Sat, Nov 4, 2017 at 4:43 AM, Tom Lane wrote: > Paul Ramsey 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

Re: [HACKERS] Parallel Plans and Cost of non-filter functions

Moin, On Fri, November 3, 2017 7:13 pm, Tom Lane wrote: > Paul Ramsey 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.

Re: [HACKERS] Parallel Plans and Cost of non-filter functions

Paul Ramsey 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

Re: [HACKERS] Parallel Plans and Cost of non-filter functions

Just clarifying myself a little, since I made a dumb error partway through. On Thu, Nov 2, 2017 at 10:09 AM, Paul Ramsey wrote: > I'm working on a custom aggregate, that generates a serialized data > format. The preparation of the geometry before being formatted is

[HACKERS] Parallel Plans and Cost of non-filter functions

I'm working on a custom aggregate, that generates a serialized data format. The preparation of the geometry before being formatted is pretty intense, so it is probably a good thing for that work to be done in parallel, in partial aggregates. Here's an example SQL call: EXPLAIN analyze SELECT