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
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 |