Re: pg_upgrade and statistics - Mailing list pgsql-hackers

From Greg Stark
Subject Re: pg_upgrade and statistics
Date
Msg-id CAM-w4HN1mfYOq+iN2D-+SfTYTrtv08HVBDXE+CgOtyXp478_8w@mail.gmail.com
Whole thread Raw
In response to Re: pg_upgrade and statistics  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: pg_upgrade and statistics  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
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.


-- 
greg


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: CREATE FOREGIN TABLE LACUNA
Next
From: Tareq Aljabban
Date:
Subject: Storage Manager crash at mdwrite()