Re: Latest plans for Utilities with HOT - Mailing list pgsql-hackers

From Pavan Deolasee
Subject Re: Latest plans for Utilities with HOT
Date
Msg-id 45EC40C3.10506@enterprisedb.com
Whole thread Raw
In response to Latest plans for Utilities with HOT  ("Simon Riggs" <simon@2ndquadrant.com>)
Responses Re: Latest plans for Utilities with HOT  ("Simon Riggs" <simon@2ndquadrant.com>)
List pgsql-hackers
Simon Riggs wrote:>> - VACUUM FULL - The best solution, for now, is to make VACUUM FULL> perform a reindex on all
indexeson the table. Chilling may require us> to modify considerably more index entries than previously. UPDATE & WAIT>
wouldbe very good, but probably should wait for the next release now,> since we now have changes to make to 4
utilities.

On my way back home, I was thinking about VACUUM FULL. Is there really
a problem with VACUUM FULL and HOT ? VF moves tuple chains in the
table and does that while holding AccessExclusive lock on the table.

If we prune the HOT-update chains (which we anyways do for lazy vacuum),
we can guarantee that the entire HOT-update chain will be moved, if
any of the tuples in the chain is moved. Also, when VF moves a tuple
chain appropriate index entries are inserted into all the indexes.
If we don't carry the HEAP_HOT_UPDATED or HEAP_ONLY_TUPLE flags
to the moved location, the HOT-update chain will be broken, but
that should not have any correctness problems. If VACUUM FULL
crashes before completeing its operation, the original HOT-update
chain would still remain valid and the new tuples will be discarded.

Is there something I am missing ?

Thanks,
Pavan


EnterpriseDB    http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: "Simon Riggs"
Date:
Subject: Re: HOT - whats next ?
Next
From: Tom Lane
Date:
Subject: Re: PrivateRefCount (for 8.3)