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 behaviour
> *is* sensitive to the c
>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 cos
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 rows, not the cost of preparing those rows.
> >
> >> This is true, as far as
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 unfortunate. Feeding tables with
>> 100ks of rows, I
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. Feeding tables with
>> 100ks
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 10ks of rows, never do, no
>
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 pretty
> intense, so it is pro
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 lengt