Re: [BUGS] Routine analyze of single column prevents standard autoanalyze from running at all
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomasz Ostrowski <tometzky+pg@ato.waw.pl>
Cc: Jim Nasby <Jim.Nasby@BlueTreble.com>, Josh berkus <josh@agliodbs.com>,
pgsql-hackers@postgresql.org
Date: 2016-06-08T14:04:51Z
Lists: pgsql-bugs, 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