Re: Problems with plan estimates in postgres_fdw - Mailing list pgsql-hackers

From Antonin Houska
Subject Re: Problems with plan estimates in postgres_fdw
Date
Msg-id 8642.1552062349@localhost
Whole thread Raw
In response to Re: Problems with plan estimates in postgres_fdw  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Responses Re: Problems with plan estimates in postgres_fdw
List pgsql-hackers
Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> wrote:

> (2019/03/01 20:16), Antonin Houska wrote:
> > Etsuro Fujita<fujita.etsuro@lab.ntt.co.jp>  wrote:
>
> >> Conversely, it appears that add_foreign_ordered_paths() added by the patchset
> >> would generate such pre-sorted paths *redundantly* when the input_rel is the
> >> final scan/join relation.  Will look into that.
> >
> > Currently I have no idea how to check the plan created by FDW at the
> > UPPERREL_ORDERED stage, except for removing the sort from the
> > UPPERREL_GROUP_AGG stage as I proposed here:
> >
> > https://www.postgresql.org/message-id/11807.1549564431%40localhost
>
> I don't understand your words "how to check the plan created by FDW". Could
> you elaborate on that a bit more?

I meant that I don't know how to verify that the plan that sends the ORDER BY
clause to the remote server was created at the UPPERREL_ORDERED and not at
UPPERREL_GROUP_AGG. However if the ORDER BY clause really should not be added
at the UPPERREL_GROUP_AGG stage and if we ensure that it no longer happens,
then mere presence of ORDER BY in the (remote) plan means that the
UPPERREL_ORDERED stage works fine.

--
Antonin Houska
https://www.cybertec-postgresql.com


pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: Update does not move row across foreign partitions in v11
Next
From: Antonin Houska
Date:
Subject: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)