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 <and...@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 <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers