HOT also usually requires setting FILLFACTOR to something other than the default for your table, so that there is guaranteed room 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@xxxxxxxx> 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@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
