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 21:45:05
Message-ID: 20200831214505.GP13613@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Aug 31, 2020 at 01:26:59PM -0400, Stephen Frost wrote:
> * Bruce Momjian (bruce(at)momjian(dot)us) wrote:
> > I actually don't know which statement above is correct, because of the
> > "forever" maintenance.
>
> I can understand not being sure which is correct, and we can all have
> different points of view on it too, but that's a much softer stance than
> what I, at least, understood from your up-thread comment which was-
>
> > I don't think there was enough value to do statistics migration just
> > for pg_upgrade [...]
>
> That statement came across to me as saying the latter statement above.
> Perhaps that wasn't what you intended it to, in which case it's good to
> have the discussion and clarify it, for others who might be following
> this thread and wondering if they should consider working on this area
> of the code or not.

I concluded that based on the fact that pg_upgrade has been used for
years and there has been almost no work on statistics upgrades.

> > 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.
>
> Feature work either requires changes to pg_dump, or not. I agree that
> features which don't require pg_dump changes are definitionally less
> work than features which do (presuming the rest of the feature is the
> same in both cases) but that isn't a justification to not have pg_dump
> support in cases where it's expected- we just don't currently expect it
> for statistics (which is a rather odd exception when you consider that
> nearly everything else that ends up in the catalog tables is included).

Agreed, but the big differences is that you can change most SQL commands
easily, e.g. system catalog changes, without any pg_dump changes, unless
you change the SQL API, while any statistics storage change would
potentially need pg_dump adjustments. And once you start doing it, you
had better keep doing it for every major release or there will be major
complaints.

> For my part, at least, I'd like to see us change that expectation, for a
> number of reasons:

Yes, there are certainly more uses now than we used to have.

--
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

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2020-08-31 21:46:22 Re: Ideas about a better API for postgres_fdw remote estimates
Previous Message Bruce Momjian 2020-08-31 21:36:40 Re: ALTER SYSTEM between upgrades