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

Re: pg_upgrade and statistics

From: Greg Stark <stark(at)mit(dot)edu>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: 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>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade and statistics
Date: 2012-03-15 17:45:16
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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.


In response to


pgsql-hackers by date

Next:From: Tareq AljabbanDate: 2012-03-15 17:49:40
Subject: Storage Manager crash at mdwrite()
Previous:From: Robert HaasDate: 2012-03-15 15:58:57

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