Re: visibility map and reltuples - Mailing list pgsql-hackers

From Greg Stark
Subject Re: visibility map and reltuples
Date
Msg-id CE7582AD-B5EF-4C28-A48F-0450472D0C76@enterprisedb.com
Whole thread Raw
In response to Re: visibility map and reltuples  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: visibility map and reltuples  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Re: visibility map and reltuples  (Greg Smith <gsmith@gregsmith.com>)
List pgsql-hackers
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.linnakangas@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


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: Sync Rep: First Thoughts on Code
Next
From: Heikki Linnakangas
Date:
Subject: Re: visibility map and reltuples