From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tomasz Ostrowski <tometzky+pg(at)ato(dot)waw(dot)pl> |
Cc: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, Josh berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [BUGS] Routine analyze of single column prevents standard autoanalyze from running at all |
Date: | 2016-06-08 14:04:51 |
Message-ID: | 18350.1465394691@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
Tomasz Ostrowski <tometzky+pg(at)ato(dot)waw(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-06-08 14:32:52 | Re: Case in Order By Ignored without warning or error |
Previous Message | Bo Ørsted Andresen | 2016-06-08 11:46:11 | Re: BUG #14180: Segmentation fault on replication slave |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-06-08 14:07:08 | Re: Parallel safety tagging of extension functions |
Previous Message | Kevin Grittner | 2016-06-08 13:40:52 | Re: [HACKERS] Re: pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold < |