Re: Using distinct in an aggregate prevents parallel execution?

From: Thomas Kellerer <spam_eater(at)gmx(dot)net>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Using distinct in an aggregate prevents parallel execution?
Date: 2018-06-06 19:12:34
Message-ID: 8e89b5e2-555d-778e-c40b-3b7c8ded5d4e@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Tom Lane schrieb am 06.06.2018 um 16:32:
> Thomas Kellerer <spam_eater(at)gmx(dot)net> writes:
>> Is this a known limitation?
>
> Yes, unless somebody has done radical restructuring of the aggregation
> code while I wasn't looking.
>
> agg(DISTINCT ...) is currently implemented inside the Agg plan node,
> so it's an indivisible black box to everything else. That was a
> simple, minimum-code-footprint method for implementing the feature
> back when; but it's got lots of drawbacks, and one is that there's
> no reasonable way to parallelize.
>
> I'd anticipate that before we could even start to think of parallelizing,
> we'd have to split out the distinct-ification processing into a separate
> plan node.
>
> agg(... ORDER BY ...) has got the same problem, and it'd likely be
> advisable to fix that at the same time.

Thansk for the explanation.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message ChatPristi 2018-06-06 20:08:04 Fw: Re: Out of memory error with PG10.3, 10.4 but not 9.3.19
Previous Message Tom Lane 2018-06-06 19:10:05 Re: Slow planning time for simple query