On Sun, 2010-05-02 at 10:34 -0400, Tom Lane wrote: > Simon Riggs <si...@2ndquadrant.com> writes: > > Not commenting further on that patch, but I notice that when we UPDATE > > the toasting algorithm takes no account of the available freespace on > > the current block. If we are updating and the space available would make > > a difference to the row length chosen, it seems like it would be more > > beneficial to trim the row and encourage HOT updates. > > That doesn't strike me as a terribly good idea: it would make the > behavior of TOAST significantly more difficult to predict. Also, what > happens if we force a row to a smaller size and then it doesn't fit > anyway (eg because someone else inserted another row on the page while > we were busy doing this)? Spend even more cycles to un-toast back to > the normal size, to be consistent with ordinary cross-page updates? > > Pretty much every previous discussion of tweaking the TOAST behavior > has focused on giving the user more control (indeed, the patch you > mention could be seen as doing that). What you're suggesting here > would give the user less control, as well as less predictability.
As long as we've considered it, I'm happy either way. You know I'm happier with more user control. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
