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: CAM-w4HN1mfYOq+iN2D-+SfTYTrtv08HVBDXE+CgOtyXp478_8w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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.

--
greg

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tareq Aljabban 2012-03-15 17:49:40 Storage Manager crash at mdwrite()
Previous Message Robert Haas 2012-03-15 15:58:57 Re: CREATE FOREGIN TABLE LACUNA