> > While I agree, that 2 might be a good compromise with low risc for > > now, I think that toasting all rows down to ~512 bytes is too narrowly > > targeted at not reading wider columns. > > Well, it is summarized here: > > http://momjian.us/expire/TOAST/SUMMARY.html > > It made non-TOAST access 2x faster, but TOAST 7x slower, and > that seemed like a good compromise.
Yes, my argument was that I expect that in the up to 1-2k range more use cases will suffer the 7x slowdown, than see the speedup. But the ratio certainly is hard to judge, and you may well be right. e.g. for me TOAST_TUPLES_PER_PAGE 8 would be ok, I have base row widths of ~700 in 2 tables that would suffer if further toasted, but none in the 1k - 2k range. I wonder whether this threshold isn't rather absolute, thus the 32k pagesize users should probably use 32. > > When suggesting a new target, I interpreted you like so: > > #define TOAST_TUPLES_PER_PAGE 4 > > #define TOAST_TUPLE_TARGET \ > > MAXALIGN_DOWN((BLCKSZ - \ > > MAXALIGN(sizeof(PageHeaderData) + > > (TOAST_TUPLES_PER_PAGE-1) * sizeof(ItemIdData))) \ > > / 16) > > So we would only toast rows wider than 2k, but once toasting, toast > > the base row down to 512. > > That is certainly not my intent, and I don't see how you > would get the 2k number from that macro. I think you are the ~2k come from TOAST_TUPLE_THRESHOLD > looking at 8.2 and not CVS HEAD. CVS HEAD has: > > #define TOAST_TUPLE_TARGET TOAST_TUPLE_THRESHOLD Nope, I meant what I said. To only change the target you would replace above macro for TOAST_TUPLE_TARGET. But I also don't see how this would be good. Andreas ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
