From: Antonin Houska <ah@cybertec.at>
To: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
cc: Tom Lane <tgl@sss.pgh.pa.us>,
    Andrew Gierth <andrew@tao11.riddles.org.uk>,
    pgsql-hackers@postgresql.org
Subject: Re: Problems with plan estimates in postgres_fdw
In-reply-to: <5C73B7FB.2010309@lab.ntt.co.jp>
References: <87pnz1aby9.fsf@news-spur.riddles.org.uk>
 <1175.1533220908@sss.pgh.pa.us> <5BB739CD.6040002@lab.ntt.co.jp>
 <5BBC4140.50403@lab.ntt.co.jp> <5C17A00E.5000005@lab.ntt.co.jp>
 <5C232F39.9060509@lab.ntt.co.jp> <5C25C7B5.2010802@lab.ntt.co.jp>
 <5C518631.5080401@lab.ntt.co.jp> <10994.1549559088@localhost>
 <5C5D778F.3080501@lab.ntt.co.jp> <5C6D474F.5010703@lab.ntt.co.jp>
 <30939.1550848901@localhost> <5C73B7FB.2010309@lab.ntt.co.jp>
Comments: In-reply-to Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
   message dated "Mon, 25 Feb 2019 18:40:11 +0900."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7519.1551439018.1@localhost>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 01 Mar 2019 12:16:58 +0100
Message-ID: <7520.1551439018@localhost>
Precedence: bulk

Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> wrote:

> (2019/02/23 0:21), Antonin Houska wrote:
> > Etsuro Fujita<fujita.etsuro@lab.ntt.co.jp>  wrote:
> =

> >>> (2019/02/08 2:04), Antonin Houska wrote:
> >>>> * regression tests: I think test(s) should be added for queries tha=
t have
> >>>> ORDER BY clause but do not have GROUP BY (and also no LIMIT / OFFSE=
T)
> >>>> clause. I haven't noticed such tests.
> =

> >> I noticed that such queries would be processed by what we already hav=
e for
> >> sort pushdown (ie, add_paths_with_pathkeys_for_rel()).  I might be mi=
ssing
> >> something, though.
> >
> > What about an ORDER BY expression that contains multiple Var nodes? Fo=
r
> > example
> >
> > SELECT * FROM foo ORDER BY x + y;
> >
> > I think the base relation should not be able to generate paths with th=
e
> > corresponding pathkeys, since its target should (besides PlaceHolderVa=
rs,
> > which should not appear in the plan of this simple query at all) only =
emit
> > individual Vars.
> =

> Actually, add_paths_with_pathkeys_for_rel() generates such pre-sorted pa=
ths
> for the base relation, as shown in the below example using HEAD without =
the
> patchset proposed in this thread:
> =

> postgres=3D# explain verbose select a+b from ft1 order by a+b;
>                                 QUERY PLAN
> ------------------------------------------------------------------------=
--
>  Foreign Scan on public.ft1  (cost=3D100.00..200.32 rows=3D2560 width=3D=
4)
>    Output: (a + b)
>    Remote SQL: SELECT a, b FROM public.t1 ORDER BY (a + b) ASC NULLS LAS=
T
> (3 rows)
> =

> I think it is OK for that function to generate such paths, as tlists for=
 such
> paths would be adjusted in apply_scanjoin_target_to_paths(), by doing
> create_projection_path() to them.

I've just checked it. The FDW constructs the (a + b) expression for the OR=
DER
BY clause on its own. It only needs to find the input vars in the relation
target.

> Conversely, it appears that add_foreign_ordered_paths() added by the pat=
chset
> 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

-- =

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