Re: Statistics mismatch between n_live_tup and actual row count

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andreas Brandl <ml(at)3(dot)141592654(dot)de>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Statistics mismatch between n_live_tup and actual row count
Date: 2011-12-10 16:08:33
Message-ID: 27170.1323533313@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Andreas Brandl <ml(at)3(dot)141592654(dot)de> writes:
>> The planner doesn't use n_live_tup;

> I'm just curious: where does the planner take the (approximate) row-count from?

It uses the tuple density estimated by the last vacuum or analyze (viz,
reltuples/relpages) and multiplies that by the current relation size.
There are various reasons for not using n_live_tup, some historical and
some still pretty relevant.

> Might there be a link between n_live_tup drifting and doing unnecessary (blind) updates, which do not change any information of a row?

Possibly. It's premature to speculate with no test case, but I'm
wondering if HOT updates confuse that arithmetic. No-op updates
would follow the HOT path as long as there was room on the page...

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Jack Christensen 2011-12-10 20:39:35 Re: Why does aggregate query allow select of non-group by or aggregate values?
Previous Message Andreas Brandl 2011-12-10 15:10:46 Re: Statistics mismatch between n_live_tup and actual row count