Re: [GENERAL] select statement against pg_stats returns inconsistent data - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [GENERAL] select statement against pg_stats returns inconsistent data
Date
Msg-id 28810.1077665316@sss.pgh.pa.us
Whole thread Raw
Responses Re: [GENERAL] select statement against pg_stats returns inconsistent  (Joe Conway <mail@joeconway.com>)
List pgsql-hackers
Shelby Cain <alyandon@yahoo.com> writes:
> The select statements return different data for
> most_commons_vals depending on whether n_distinct is
> included in the select clause or not.
> I only seem to get the behavior below against int8
> columns - but I haven't interated through every
> conceivable data type either.

Hoo, I'm surprised no one noticed this during 7.4 development/testing.
The problem applies for any datatype that requires double alignment,
which includes int8, float8, and timestamp as well as most of the
geometric types.  pg_statistic is declared as using type "anyarray",
and this type really needs to be marked as requiring double alignment
so that arrays of double-aligned datatypes will come out correctly.

The correct source fix is a one-line change in pg_type.h, but this will
not propagate into existing databases without an initdb.  It looks like
what you'd need to do to fix an existing database is

-- clear out broken data in pg_statistic
DELETE FROM pg_statistic;
-- this should update 1 row:
UPDATE pg_type SET typalign = 'd' WHERE oid = 2277;
-- this should update 6 rows:
UPDATE pg_attribute SET attalign = 'd' WHERE atttypid = 2277;
-- might be a good idea to start a fresh backend at this point
-- repopulate pg_statistic
ANALYZE;

Ugh :-(

            regards, tom lane

pgsql-hackers by date:

Previous
From: Mike Mascari
Date:
Subject: Re: Is indexing broken for bigint columns?
Next
From: "Dann Corbit"
Date:
Subject: Re: Is indexing broken for bigint columns?