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 16:47:25
Message-ID: 20200831164725.GE13613@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Aug 31, 2020 at 12:19:52PM -0400, Stephen Frost wrote:
> * Bruce Momjian (bruce(at)momjian(dot)us) wrote:
> > I don't think there was enough value to do statistics migration just for
> > pg_upgrade, but doing it for pg_upgrade and FDWs seems like it might
> > have enough demand to justify the required work and maintenance.
>
> Not sure that it really matters much, but I disagree with the assessment
> that there wasn't enough value to do it for pg_upgrade; I feel that it
> just hasn't been something that's had enough people interested in
> working on it, which isn't the same thing.

I am not sure what point you are trying to make, but if it had enough
value, wouldn't people work on it, or are you saying that it had enough
value, but people didn't realize it, so didn't work on it? I guess I
can see that. For me, it was the maintenance burden that always scared
me from getting involved since it would be the rare case where
pg_upgrade would have to be modified for perhaps every major release.

> If a good patch showed up tomorrow, with someone willing to spend time
> on it, I definitely think it'd be something we should include even if
> it's just for pg_upgrade. A solution that works for both pg_upgrade and
> the postgres FDW would be even better, of course.

Yep, see above. The problem isn't mostly the initial patch, but someone
who is going to work on it and test it for every major release,
potentially forever. Frankly, this is a pg_dump feature, rather than
something pg_upgrade should be doing, because not having to run ANALYZE
after restoring a dump is also a needed feature.

--
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 Stephen Frost 2020-08-31 16:56:21 Re: Ideas about a better API for postgres_fdw remote estimates
Previous Message Tomas Vondra 2020-08-31 16:32:00 Re: list of extended statistics on psql