Re: Ideas about a better API for postgres_fdw remote estimates

From: Ashutosh Bapat <ashutosh(dot)bapat(at)2ndquadrant(dot)com>
To: "Andrey V(dot) Lepikhov" <a(dot)lepikhov(at)postgrespro(dot)ru>
Cc: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Subject: Re: Ideas about a better API for postgres_fdw remote estimates
Date: 2020-09-04 13:23:37
Message-ID: CAG-ACPWRAao++Fc+A_P7-+Z5d7d4ze72DiRvbNr7Rw29iPRcUQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 3 Sep 2020 at 10:44, Andrey V. Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru>
wrote:

> On 8/31/20 6:19 PM, Ashutosh Bapat wrote:
> > On Mon, Aug 31, 2020 at 3:36 PM Andrey V. Lepikhov
> > <a(dot)lepikhov(at)postgrespro(dot)ru> wrote:
> >>
> >> Thanks for this helpful feedback.
> > I think the patch has some other problems like it works only for
> > regular tables on foreign server but a foreign table can be pointing
> > to any relation like a materialized view, partitioned table or a
> > foreign table on the foreign server all of which have statistics
> > associated with them. I didn't look closely but it does not consider
> > that the foreign table may not have all the columns from the relation
> > on the foreign server or may have different names. But I think those
> > problems are kind of secondary. We have to agree on the design first.
> >
> In accordance with discussion i made some changes in the patch:
> 1. The extract statistic routine moved into the core.
>

Bulk of the patch implements the statistics conversion to and fro json
format. I am still not sure whether we need all of that code here. Can we
re-use pg_stats view? That is converting some of the OIDs to names. I agree
with anyarray but if that's a problem here it's also a problem for pg_stats
view, isn't it? If we can reduce the stats handling code to a minimum or
use it for some other purpose as well e.g. pg_stats enhancement, the code
changes required will be far less compared to the value that this patch
provides.

--
Best Wishes,
Ashutosh

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-09-04 13:58:35 Re: Rare deadlock failure in create_am test
Previous Message Tomas Vondra 2020-09-04 12:56:40 Re: Disk-based hash aggregate's cost model