Re: Stopgap solution for table-size-estimate updating problem

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Stopgap solution for table-size-estimate updating problem
Дата
Msg-id 21662.1101681353@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Stopgap solution for table-size-estimate updating  (Simon Riggs <simon@2ndquadrant.com>)
Ответы Re: Stopgap solution for table-size-estimate updating  (Simon Riggs <simon@2ndquadrant.com>)
Список pgsql-hackers
Simon Riggs <simon@2ndquadrant.com> writes:
> Given we expect an underestimate, can we put in a correction factor
> should the estimate get really low...sounds like we could end up
> choosing nested joins more often when we should have chosen merge joins.

One possibility: vacuum already knows how many tuples it removed.  We
could set reltuples equal to, say, the mean of the number-of-tuples-
after-vacuuming and the number-of-tuples-before.  In a steady state
situation this would represent a fairly reasonable choice.  In cases
where the table size has actually decreased permanently, it'd take a few
cycles of vacuuming before reltuples converges to the new value, but that
doesn't seem too bad.

A standalone ANALYZE should still do what it does now, though, I think;
namely set reltuples to its best estimate of the current value.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Thomas Hallgren
Дата:
Сообщение: Re: Status of server side Large Object support?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Adding a suffix array index