HOT also usually requires setting FILLFACTOR to something other than the default for your table, so that there is
guaranteedroom in the page to modify data without allocating a new page.
If you have fillfactor=75, then basically this proposal is already done -- each page has 25% temp space for updates in
it. With the caveat that that is only true if the updates are to columns without indexes.
On Nov 12, 2010, at 7:37 AM, Kenneth Marshall wrote:
> On Fri, Nov 12, 2010 at 07:34:36AM -0800, bricklen wrote:
>> On Fri, Nov 12, 2010 at 5:52 AM, Kenneth Marshall <ktm@rice.edu> wrote:
>>>
>>> I cannot speak to your suggestion, but it sounds like you are not
>>> vacuuming enough and a lot of the bloat/randomization would be helped
>>> by making use of HOT updates in which the updates are all in the same
>>> page and are reclaimed almost immediately.
>>>
>>> Regards,
>>> Ken
>>
>> IIRC, HOT only operates on non-indexed columns, so if you the tables
>> are heavily indexed you won't get the full benefit of HOT. I could be
>> wrong though.
>>
>
> That is true, but if they are truly having as big a bloat problem
> as the message indicated, it would be worth designing the schema
> to leverage HOT for the very frequent updates.
>
> Cheers,
> Ken
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
