Re: Ideas about a better API for postgres_fdw remote estimates

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrey Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru>, 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-08-31 17:08:17
Message-ID: 20200831170817.GF13613@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Aug 31, 2020 at 12:56:21PM -0400, Stephen Frost wrote:
> Greetings,
> * Bruce Momjian (bruce(at)momjian(dot)us) wrote:
> The point I was making was that it has value and people did realize it
> but there's only so many resources to go around when it comes to hacking
> on PG and therefore it simply hasn't been done yet.
>
> There's a big difference between "yes, we all agree that would be good
> to have, but no one has had time to work on it" and "we don't think this
> is worth having because of the maintenance work it'd require." The
> latter shuts down anyone thinking of working on it, which is why I said
> anything.

I actually don't know which statement above is correct, because of the
"forever" maintenance.

> I tend to agree with it being more of a pg_dump issue- but that also
> shows that your assessment above doesn't actually fit, because we
> definitely change pg_dump every release. Consider that if someone wants
> to add some new option to CREATE TABLE, which gets remembered in the
> catalog, they have to make sure that pg_dump support is added for that.
> If we added the statistics export/import to pg_dump, someone changing
> those parts of the system would also be expected to update pg_dump to
> manage those changes, including working with older versions of PG.

Yes, very true, but technically any change in any aspect of the
statistics system would require modification of the statistics dump,
which usually isn't required for most feature changes.

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EnterpriseDB https://enterprisedb.com

The usefulness of a cup is in its emptiness, Bruce Lee

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-08-31 17:22:11 Re: Get rid of runtime handling of AlternativeSubPlan?
Previous Message Alvaro Herrera 2020-08-31 17:00:50 Re: Clang UndefinedBehaviorSanitize (Postgres14) Detected undefined-behavior