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
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 |