On Sat, May 18, 2019 at 03:45:11PM -0400, Tom Lane wrote:
Tomas Vondra <tomas.von...@2ndquadrant.com> writes:
On Sat, May 18, 2019 at 11:49:06AM -0700, Andres Freund wrote:
On Sat, 18 May 2019 at 16:13, Tom Lane <t...@sss.pgh.pa.us> wrote:
It seems like what we need here is to have a separation between the
*definition* of a stats object (which is what pg_dump needs access
to) and the current actual *data* in it.
Otoh, having a suboptimal catalog representation that we'll likely have
to change in one of the next releases also isn't great. Seems likely
that we'll need post beta1 catversion bumps anyway?
But that's not an issue intruduced by PG12, it works like that even for
the extended statistics introduced in PG10.
Yeah, but no time like the present to fix it if it's wrong ...
Sorry, not sure I understand. Are you saying we should try to rework
this before the beta1 release, or that we don't have time to do that?
I think we have four options - rework it before beta1, rework it after
beta1, rework it in PG13 and leave it as it is now.
If the pg_dump thing si the only issue, maybe there's a simple solution
that reworking all the catalogs. Not sure. Are there any other reasons
why the current catalog representation would be suboptimal, or do we
have some precedent of a catalog split this way? I can't think of any.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
