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 CAPmGK15EoA_yHycO9bXgNRze0WbiSLKjz_5jd0Xwg4PVycHmzA@mail.gmail.com
Whole thread Raw
In response to Re: Partitioning and postgres_fdw optimisations for multi-tenancy  (Andrey Lepikhov <a.lepikhov@postgrespro.ru>)
Responses Re: Partitioning and postgres_fdw optimisations for multi-tenancy  (Alexey Kondratov <a.kondratov@postgrespro.ru>)
Re: Partitioning and postgres_fdw optimisations for multi-tenancy  ("Andrey V. Lepikhov" <a.lepikhov@postgrespro.ru>)
List pgsql-hackers
On Thu, Jul 16, 2020 at 8:56 PM Andrey Lepikhov
<a.lepikhov@postgrespro.ru> wrote:
> On 7/16/20 9:55 AM, Etsuro Fujita wrote:

> >>>> On Tue, Jul 14, 2020 at 12:48 AM Alexey Kondratov
> >>>> <a.kondratov@postgrespro.ru> wrote:
> >>>>> Some real-life test queries show, that all single-node queries aren't
> >>>>> pushed-down to the required node. For example:
> >>>>>
> >>>>> SELECT
> >>>>>       *
> >>>>> FROM
> >>>>>       documents
> >>>>>       INNER JOIN users ON documents.user_id = users.id
> >>>>> WHERE
> >>>>>       documents.company_id = 5
> >>>>>       AND users.company_id = 5;

> > PWJ cannot be applied
> > to the join due to the limitation of the PWJ matching logic.  See the
> > discussion started in [1].  I think the patch in [2] would address
> > this issue as well, though the patch is under review.

> I think, discussion [1] is little relevant to the current task. Here we
> join not on partition attribute and PWJ can't be used at all.

The main point of the discussion is to determine whether PWJ can be
used for a join between partitioned tables, based on
EquivalenceClasses, not just join clauses created by
build_joinrel_restrictlist().  For the above join, for example, the
patch in [2] would derive a join clause "documents.company_id =
users.company_id" from an EquivalenceClass that recorded the knowledge
"documents.company_id = 5" and "users.company_id = 5", and then the
planner would consider from it that PWJ can be used for the join.

Best regards,
Etsuro Fujita



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: renaming configure.in to configure.ac
Next
From: Alexey Kondratov
Date:
Subject: Re: Partitioning and postgres_fdw optimisations for multi-tenancy