On Wed, 2007-03-28 at 14:08 -0400, Tom Lane wrote:
> Gregory Stark <stark@enterprisedb.com> writes:
> > "Tom Lane" <tgl@sss.pgh.pa.us> writes:
> >> I also think that we ought to add TOAST_MAX_CHUNK_SIZE to the set of
> >> compiled-in parameters that are recorded in pg_control and checked for
> >> compatibility at startup (like BLCKSZ) --- this will prevent anyone from
> >> shooting themselves in the foot while experimenting.
>
> > Is there any reason to experiment with this? I would have thought we would
> > divorce TOAST_MAX_CHUNK_SIZE from TOAST_THRESHOLD and hard code it as the same
> > expression that's there now. Ie, the largest size that can fit in a page.
>
> No, right now it's the largest size that you can fit 4 on a page. It's
> not obvious to me that 4 is optimal once it's divorced from TOAST_THRESHOLD.
> It seems possible that the correct number is 1, and even if it's useful
> to keep the tuples smaller than that, there's no reason to assume 4 is
> the best number per page.
Well it certainly seems worth separating them. It does seem possible
that recursive toasting effected some of the earlier results we looked
at.
Would you like me to do this, or will you?
I'll look again at the possibility for setting TOAST_THRESHOLD and
re-cast the test patch I have for production use. But either way it's
going to be a couple of days after freeze now.
I'd like to get some mechanism for reducing WAL volume into 8.3, whether
its configurable toast or WAL reduction for UPDATEs. If for no other
reason than making backup and availability solutions more manageable.
-- Simon Riggs EnterpriseDB http://www.enterprisedb.com
