Re: Statistics mismatch between n_live_tup and actual row count
От | Tom Lane |
---|---|
Тема | Re: Statistics mismatch between n_live_tup and actual row count |
Дата | |
Msg-id | 27170.1323533313@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Statistics mismatch between n_live_tup and actual row count (Andreas Brandl <ml@3.141592654.de>) |
Ответы |
Re: Statistics mismatch between n_live_tup and actual row
count
Re: Statistics mismatch between n_live_tup and actual row count |
Список | pgsql-general |
Andreas Brandl <ml@3.141592654.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 informationof 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
В списке pgsql-general по дате отправления: