From: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> |
---|---|
To: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
Cc: | Pavan Deolasee <pavan(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: HOT patch, missing things |
Date: | 2007-08-07 19:59:18 |
Message-ID: | 46B8CF16.9010200@kaltenbrunner.cc |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas wrote:
> 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.
ah I see - that sounds like much less a problem than I thought it was.
Thanks for the explaination!
>
> 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.
yep - I'm already playing with -HEAD for some of our production
databases and the size improvements in itself are a very nice thing.
Stefan
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2007-08-07 20:07:38 | Re: GIT patch |
Previous Message | Arthernan | 2007-08-07 19:53:14 | Re: Internal Postgre SQL documentation |