Re: Partitioning and postgres_fdw optimisations for multi-tenancy - Mailing list pgsql-hackers

From Etsuro Fujita
Subject Re: Partitioning and postgres_fdw optimisations for multi-tenancy
Date
Msg-id CAPmGK17pd91953VHhCTDMGo+FRaRYYeqpsN4Lu40qo171ofAHg@mail.gmail.com
Whole thread Raw
In response to Re: Partitioning and postgres_fdw optimisations for multi-tenancy  (Alexey Kondratov <a.kondratov@postgrespro.ru>)
Responses Re: Partitioning and postgres_fdw optimisations for multi-tenancy
List pgsql-hackers
On Fri, Jul 17, 2020 at 1:56 AM Alexey Kondratov
<a.kondratov@postgrespro.ru> wrote:
> However, there is an issue with aggregates as well. For a query like:
>
> SELECT
>      count(*)
> FROM
>      documents
> WHERE
>      company_id = 5;
>
> It would be great to teach planner to understand, that it's a
> partition-wise aggregate as well, even without GROUP BY company_id,
> which doesn't always help as well. I'll try to look closer on this
> problem, but if you have any thoughts about it, then I'd be glad to
> know.

The reason why the aggregation count(*) isn't pushed down to the
remote side is: 1) we allow the FDW to push the aggregation down only
when the input relation to the aggregation is a foreign (base or join)
relation (see create_grouping_paths()), but 2) for your case the input
relation would be an append relation that contains the foreign
partition as only one child relation, NOT just the foreign partition.
The resulting Append path would be removed in the postprocessing (see
[1]), but that would be too late for the FDW to do the push-down work.
I have no idea what to do about this issue.

Best regards,
Etsuro Fujita

[1]
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=8edd0e79460b414b1d971895312e549e95e12e4f;hp=f21668f328c864c6b9290f39d41774cb2422f98e



pgsql-hackers by date:

Previous
From: Rémi Lapeyre
Date:
Subject: [PATCH v3 2/2] Add header matching mode to "COPY FROM"
Next
From: Tom Lane
Date:
Subject: Re: Encoding of src/timezone/tznames/Europe.txt