Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum
От | Kevin Grittner |
---|---|
Тема | Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum |
Дата | |
Msg-id | 4DDE475B020000250003DD63@gw.wicourts.gov обсуждение исходный текст |
Ответ на | Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> wrote: > I think we should really consider replacing reltuples with > reltupledensity at some point. I continue to be afraid that using > a decaying average in this case is going to end up overweighting > the values from some portion of the table that's getting scanned > repeatedly, at the expense of other portions of the table that are > not getting scanned at all. Now, perhaps experience will prove > that's not a problem. But storing relpages and reltupledensity > separately would give us more flexibility, because we could feel > free to bump relpages even when we're not sure what to do about > reltupledensity. That would help Florian's problem quite a lot, > even if we did nothing else. Given how trivial it would be to adjust reltuples to keep its ratio to relpages about the same when we don't have a new "hard" number, but some evidence that we should fudge our previous value, I don't see where this change buys us much. It seems to mostly obfuscate the fact that we're changing our assumption about how many tuples we have. I would rather that we did that explicitly with code comments about why it's justified than to slip it in the way you suggest. -Kevin
В списке pgsql-hackers по дате отправления: