Skip site navigation (1) Skip section navigation (2)

Re: pg_upgrade and statistics

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kevin Grittner <kevin(dot)grittner(at)wicourts(dot)gov>, Daniel Farina <daniel(at)heroku(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade and statistics
Date: 2012-03-15 18:48:09
Message-ID: 1331835103-sup-5338@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-hackers
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(at)dunslane(dot)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(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Responses

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2012-03-15 19:25:53
Subject: Re: patch: autocomplete for functions
Previous:From: Tom LaneDate: 2012-03-15 18:31:06
Subject: Re: pg_upgrade and statistics

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group