From: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
---|---|
To: | Alexander Pyhalov <a(dot)pyhalov(at)postgrespro(dot)ru> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Partial aggregates pushdown |
Date: | 2021-10-19 13:25:52 |
Message-ID: | 504e576d-984f-d73c-2694-8ee9624f8def@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/19/21 08:56, Alexander Pyhalov wrote:
> Hi.
>
> Tomas Vondra писал 2021-10-15 17:56:
>> As for the proposed approach, it's probably good enough for the first
>> version to restrict this to aggregates where the aggregate result is
>> sufficient, i.e. we don't need any new export/import procedures.
>>
>> But it's very unlikely we'd want to restrict it the way the patch does
>> it, i.e. based on aggregate name. That's both fragile (people can
>> create new aggregates with such name) and against the PostgreSQL
>> extensibility (people may implement custom aggregates, but won't be
>> able to benefit from this just because of name).
>>
>> So for v0 maybe, but I think there neeeds to be a way to relax this in
>> some way, for example we could add a new flag to pg_aggregate to mark
>> aggregates supporting this.
>>
>
> Updated patch to mark aggregates as pushdown-safe in pg_aggregates.
>
> So far have no solution for aggregates with internal aggtranstype.
Thanks. Please add it to the next CF, so that we don't lose track of it.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | David Steele | 2021-10-19 13:38:37 | Re: parallelizing the archiver |
Previous Message | Tom Lane | 2021-10-19 13:23:35 | Re: Refactoring pg_dump's getTables() |