Re: [BUGS] Routine analyze of single column prevents standard autoanalyze from running at all - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [BUGS] Routine analyze of single column prevents standard autoanalyze from running at all
Date
Msg-id 18350.1465394691@sss.pgh.pa.us
Whole thread Raw
In response to Re: [BUGS] Routine analyze of single column prevents standard autoanalyze from running at all  (Tomasz Ostrowski <tometzky+pg@ato.waw.pl>)
List pgsql-hackers
Tomasz Ostrowski <tometzky+pg@ato.waw.pl> writes:
> W dniu 2016-06-08 o 05:04, Tom Lane pisze:
>> Yeah, my guess is that the OP's example where analyzing just one column
>> was significantly cheaper boiled down to some of the other columns being
>> mostly toasted data.  Otherwise it's hard to see how there's much more
>> expense in analyzing them all.

> Actually no - this volatile column has smaller "statistics" than most of 
> the table, so analyzing it is much faster when it's data is not in RAM. 

Oh, so you *will* be vulnerable to the side-effect we wondered about
earlier, wherein the manual ANALYZE scans fewer blocks and may therefore
derive a less-accurate tuple count estimate than auto-analyze gets.
It'll be interesting to see how the fix plays out for you --- please pay
attention to whether the pg_stat_all_tables.n_live_tup/n_dead_tup numbers
jump around in unexpected ways.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Kevin Grittner
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <
Next
From: Robert Haas
Date:
Subject: Re: Parallel safety tagging of extension functions