I wonder if we should switch to keeping reltuplesperpage instead. Then
a partial vacuum could update it by taking the average number of
tuples per page forbthe pages it saw. Perhaps adjusting it to the
weights average between the old value and the new value based on how
many pages were seen.
I suppose there's no reason we can't update reltuples using that same
logic though it would be a big opaque.
--
Greg
On 15 Dec 2008, at 04:01, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com
> wrote:
Heikki Linnakangas wrote:
Ned T. Crigler wrote:
It appears that the visibility map patch is causing
pg_class.reltuples to be
set improperly after a vacuum. For example, it is set to 0 if the
map
indicated that no pages in the heap needed to be scanned.
Perhaps reltuples should not be updated unless every page was
scanned during
the vacuum?
Yeah, vacuum shouldn't overwrite reltuples if it hasn't scanned all
pages.
Because we use reltuples divided by relpages in the planner, we
probably shouldn't update relpages either if we don't update
reltuples. Otherwise, if the table has grown a lot since we last
updated reltuples, the reltuples / relpages ratio would be less, not
more, accurate, if relpages is updated to a new higher value but
reltuples is not.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
