Hi,

> Andreas Brandl <m...@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 (besides it 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 information of a row?

Thank you!

Best regards
Andreas

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Reply via email to