Hi,
Le 1 août 09 à 06:08, Robert Haas a écrit :
I'm lost. I think you're getting the new column attdistinct mixed up
with the existing column stadistinct. attdistinct is always going to
have whatever value you assign it. stadistinct will get attdistinct
!= 0 ? attdistinct : <result of analyze calculation>.
haha!
Sorry about that, I felt like I had to run against time and once again
I lost.
dim=# alter table foo alter column x set distinct 0.25;
ALTER TABLE
dim=# select stadistinct from pg_statistic where starelid =
'foo'::regclass;
-[ RECORD 1 ]-----
stadistinct | 0.25
dim=# alter table foo alter column x set distinct 0;
ALTER TABLE
dim=# analyze verbose foo;
INFO: analyzing "public.foo"
INFO: "foo": scanned 4 of 4 pages, containing 1000 live rows and 0
dead rows; 1000 rows in sample, 1000 estimated total rows
ANALYZE
dim=# select stadistinct from pg_statistic where starelid =
'foo'::regclass;
stadistinct
-------------
-0.652
(1 row)
I'm back on track, it seems. Time to further test this, but code
review is ok for me (except for the strange new error already
mentioned), doc is ok too, and basic behaviour is sane. I just checked
pg_dump dim|psql foo and new database (foo) has same explicit distinct
settings than origin, both for pg_attribute and pg_statistic.
Unless you want me to test for impact on planner choices (even if we
already know it has impact on pg_statistic), I'd say it's ready for
commiter.
--
dim
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
