Re: HOT patch, missing things - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: HOT patch, missing things
Date
Msg-id 46B8C497.5020508@enterprisedb.com
Whole thread Raw
In response to Re: HOT patch, missing things  (Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>)
Responses Re: HOT patch, missing things  (Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>)
List pgsql-hackers
Stefan Kaltenbrunner wrote:
> Heikki Linnakangas wrote:
>> There's three things clearly missing in the patch:
>>
>> 1. HOT updates on tables with expression or partial indexes. Hasn't been
>> done yet because it should be pretty straightforward and we've had more
>> important things to do. Though not critical, should be finished before
>> release in my opinion.
> 
> sounds like a rather common use case to me and I think this should
> really be in a patch that is accepted for 8.3...
> 
>> 2. Pointer swinging. At the moment, after a row is HOT updated, the only
>> way to get rid of the redirecting line pointer is to run VACUUM FULL or
>> CLUSTER (or delete or cold update the row and vacuum). If we want to
>> implement pointer swinging before release, we have to get started now.
>> If we're happy to release without it and address the issue in later
>> releases if it seems important, we need to make a conscious decision on
>> that, now. I personally think we can release without it.
> 
> hmm - I don't really understand most of the stuff behind HOT but does
> this mean that VACUUM FULL (or CLUSTER) is becoming a recommended or
> even required routine maintenance task for people using HOT ?

No. A redirecting line pointer only takes 4 bytes, which isn't that much
in the scheme of things. If you don't mind wasting those 4 bytes per HOT
updated row, you don't need to run VACUUM FULL.

Note that 8.3 will decrease the tuple header size by 4 bytes thanks to
the combocid patch, and the varvarlen patch saves some more space on
tuples with short varlen fields. Even if you have an extra line pointer
for every row, 8.3 will still be at least as good as 8.2 with regard to
storage size.

--  Heikki Linnakangas EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: "Simon Riggs"
Date:
Subject: Re: HOT pgbench results
Next
From: Gregory Stark
Date:
Subject: Re: HOT pgbench results