Excerpts from Greg Stark's message of jue mar 15 14:45:16 -0300 2012:
> On Thu, Mar 15, 2012 at 3:15 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
> >
> > You're not the only person who could do that. I don't think this is all down
> > to you. It should just be understood that if the stats format is changed,
> > adjusting pg_upgrade needs to be part of the change. When we modified how
> > enums worked, we adjusted pg_upgrade at the same time. That sort of thing
> > seems totally reasonable to me.
> >
> > I haven't looked at it, but I'm wondering how hard it is going to be in
> > practice?
>
> Historically pg_statistic has been pretty static. But that seems like
> a negative, not a positive -- a big part of my fear here is that it
> really really needs a lot of work to improve the statistics. I *hope*
> they get knocked around dramatically in each of the next few versions
> to handle multi-column stats, something to replace correlation that's
> more useful, custom stats functions for more data types, stats
> specifically for partitioned tables, etc. I wouldn't want to see any
> reason to hold back on these changes.
What Peter proposed seems to me pretty reasonable, in the sense that it
should be possible to come up with a function that creates some text
representation of whatever is in pg_statistic, and another function to
load that data into the new catalog(s). There's no need to keep
pg_statistic binary-compatible, or even continue to have only
pg_statistic (IIRC Zoltan/Hans-Jurgen patch for cross-column stats adds
a new catalog, pg_statistic2 or similar). If the upgrade target release
has room for more/improved stats, that's fine -- they'll be unused after
loading the stats from the dump. And the old stats can be
reacommodated, if necessary.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
