Re: Surprising dead_tuple_count from pgstattuple - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Surprising dead_tuple_count from pgstattuple
Date
Msg-id AANLkTikaWo2pkEnn-mjYLMEO6EnEjWh9Xs1ZdKUDrWzW@mail.gmail.com
Whole thread Raw
In response to Re: Surprising dead_tuple_count from pgstattuple  (Itagaki Takahiro <itagaki.takahiro@gmail.com>)
Responses Re: Surprising dead_tuple_count from pgstattuple
List pgsql-hackers
On Fri, Aug 6, 2010 at 9:11 PM, Itagaki Takahiro
<itagaki.takahiro@gmail.com> wrote:
> 2010/8/7 Gordon Shannon <gordo169@gmail.com>:
>> 1. I delete 10,000 rows.
>> pgstattuple.dead_tuple_count -> 10000
>>
>> 2. I delete 15,000 more rows.
>> pgstattuple.dead_tuple_count -> 15000 ??
>>
>> pgstattuple now appears to count the earlier 10K deleted tuples as no longer
>> dead, but free space.
>
> I think it's expected behavior that comes from HOT page reclaim.
> The second DELETE not only deleted rows but also removed physical
> tuples that were deleted in 1. Missing dead rows were pruned by HOT.

What would have triggered a HOT prune at any point in this operation?
And why would it have reclaimed all of the deleted rows?

My thought would be "is autovacuum running in the background in
between these commands?".

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company


pgsql-hackers by date:

Previous
From: Itagaki Takahiro
Date:
Subject: Re: Surprising dead_tuple_count from pgstattuple
Next
From: Tom Lane
Date:
Subject: Re: Functional dependencies and GROUP BY