From: Bruce Momjian <bruce@momjian.us>
To: Stephen Frost <sfrost@snowman.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org, Etsuro Fujita <etsuro.fujita@gmail.com>
Cc: Jeff Janes <jeff.janes@gmail.com>
Subject: Re: Ideas about a better API for postgres_fdw remote estimates
Date: Mon, 13 Jul 2020 21:32:19 -0400
Message-ID: <20200714013219.GD32422@momjian.us> (raw)
In-Reply-To: <20200706152828.GG3125@tamriel.snowman.net>
References: <1155731.1593832096@sss.pgh.pa.us>
<20200705170601.GD3125@tamriel.snowman.net>
<1301903.1593970603@sss.pgh.pa.us>
<20200705174817.GE3125@tamriel.snowman.net>
<1309399.1593980722@sss.pgh.pa.us>
<20200706141114.GF3125@tamriel.snowman.net>
<1374896.1594047946@sss.pgh.pa.us>
<20200706152828.GG3125@tamriel.snowman.net>
On Mon, Jul 6, 2020 at 11:28:28AM -0400, Stephen Frost wrote:
> > Yeah, thinking about it as a function that inspects partial planner
> > results, it might be useful for other purposes besides postgres_fdw.
> > As I said before, I don't think this necessarily has to be bundled as
> > part of postgres_fdw. That still doesn't make it part of EXPLAIN.
>
> Providing it as a function rather than through EXPLAIN does make a bit
> more sense if we're going to skip things like the lookups you mention
> above. I'm still inclined to have it be a part of core rather than
> having it as postgres_fdw though. I'm not completely against it being
> part of postgres_fdw... but I would think that would really be
> appropriate if it's actually using something in postgres_fdw, but if
> everything that it's doing is part of core and nothing related
> specifically to the postgres FDW, then having it as part of core makes
> more sense to me. Also, having it as part of core would make it more
> appropriate for other tools to look at and adding that kind of
> inspection capability for partial planner results could be very
> interesting for tools like pgAdmin and such.
I agree the statistics extraction should probably be part of core.
There is the goal if FDWs returning data, and returning the data
quickly. I think we can require all-new FDW servers to get improved
performance. I am not even clear if we have a full understanding of the
performance characteristics of FDWs yet. I know Tomas did some research
on its DML behavior, but other than that, I haven't seen much.
On a related note, I have wished to be able to see all the costs
associated with plans not chosen, and I think others would like that as
well. Getting multiple costs for a query goes in that direction.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
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: bruce@momjian.us, sfrost@snowman.net, tgl@sss.pgh.pa.us, etsuro.fujita@gmail.com, jeff.janes@gmail.com
Subject: Re: Ideas about a better API for postgres_fdw remote estimates
In-Reply-To: <20200714013219.GD32422@momjian.us>
* 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