Hi,
> Andreas Brandl <ml@3.141592654.de> writes:
> > we're currently investigating a statistics issue on postgres. We
> > have some tables which frequently show up with strange values for
> > n_live_tup. If you compare those values with a count on that
> > particular table, there is a mismatch of factor 10-30. This causes
> > the planner to come up with very bad plans (we also have this issue
> > on bigger table like the one below).
>
> The planner doesn't use n_live_tup; the only thing that that's used
> for
> is decisions about when to autovacuum/autoanalyze. So you have two
> problems here not one.
So, you're saying that having a mismatch between n_live_tup and the actual row count is not that much of a problem
(besidesit influences when to auto-vacuum/analyze), right?
I'm just curious: where does the planner take the (approximate) row-count from?
> Can you provide a test case for the n_live_tup drift? That is,
> something that when done over and over causes n_live_tup to get
> further
> and further from reality?
I'll try to implement a minimal piece of code showing this, although I'm not sure if this will work.
Might there be a link between n_live_tup drifting and doing unnecessary (blind) updates, which do not change any
informationof a row?
Thank you!
Best regards
Andreas
