From: Antonin Houska <ah@cybertec.at>
To: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Gierth <andrew@tao11.riddles.org.uk>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Problems with plan estimates in postgres_fdw
Date: Mon, 04 Mar 2019 08:46:17 +0100
Message-ID: <26194.1551685577@localhost> (raw)
In-Reply-To: <5C7928C7.50507@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>
<19433.1549962210@localhost>
<5C669DFD.30002@lab.ntt.co.jp>
<16616.1550234762@localhost>
<5C6A5FD3.8080102@lab.ntt.co.jp>
<30524.1550499671@localhost>
<5C6BBD7A.1030702@lab.ntt.co.jp>
<29190.1550843669@localhost>
<5C73C403.7080109@lab.ntt.co.jp>
<7273.1551438041@localhost>
<5C7928C7.50507@lab.ntt.co.jp>
Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> wrote:
> (2019/03/01 20:00), Antonin Houska wrote:
> > Etsuro Fujita<fujita.etsuro@lab.ntt.co.jp> wrote:
> > It's still unclear to me why add_foreign_ordered_paths() passes the input
> > relation (input_rel) to estimate_path_cost_size(). If it passed the output rel
> > (i.e. ordered_rel in this case) like add_foreign_grouping_paths() does, then
> > foreignrel->reltarget should contain the random() function. (What I see now is
> > that create_ordered_paths() leaves ordered_rel->reltarget empty, but that's
> > another problem to be fixed.)
> >
> > Do you still see a reason to call estimate_path_cost_size() this way?
>
> Yeah, the reason for that is because we can estimate the costs of sorting for
> the final scan/join relation using the existing code as-is that estimates the
> costs of sorting for base or join relations, except for tlist eval cost
> adjustment. As you mentioned, we could pass ordered_rel to
> estimate_path_cost_size(), but if so, I think we would need to get input_rel
> (ie, the final scan/join relation) from ordered_rel within
> estimate_path_cost_size(), to use that code, which would not be great.
After some more thought I suggest that estimate_path_cost_size() is redesigned
before your patch gets applied. The function is quite hard to read if - with
your patch applied - the "foreignrel" argument sometimes means the output
relation and other times the input one. I takes some effort to "switch
context" between these two perspectives when I read the code.
Perhaps both input and output relation should be passed to the function now,
and maybe also UpperRelationKind of the output relation. And maybe it's even
worth moving some code into a subroutine that handles only the upper relation.
Originally the function could only handle base relations, then join relation
was added, then one kind of upper relation (UPPERREL_GROUP_AGG) was added and
eventually the function will need to handle multiple kinds of upper
relation. It should be no surprise if such an amount of changes makes the
original signature insufficient.
--
Antonin Houska
https://www.cybertec-postgresql.com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: ah@cybertec.at, fujita.etsuro@lab.ntt.co.jp, tgl@sss.pgh.pa.us, andrew@tao11.riddles.org.uk
Subject: Re: Problems with plan estimates in postgres_fdw
In-Reply-To: <26194.1551685577@localhost>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox