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
|
Список | 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 по дате отправления: