"Tom Lane" <[EMAIL PROTECTED]> writes: > Gregory Stark <[EMAIL PROTECTED]> writes: >> You keep suggesting things that I've previously considered and rejected -- >> perhaps prematurely. Off the top of my head I recall the following four >> options from our discussions. It looks like we're circling around option 4. > > No, I think I'm arguing for option 3.
oops, sorry, got my own numbering mixed up. >> And I take it you're not worried about sites that might not detoast a datum >> or >> detoast one in the wrong memory context where previously they were guaranteed >> it wouldn't generate a copy? In particular I'm worried about btree code and >> plpgsql row/record handling. > > Any such site is already broken, because with the proposed design, code > is only exposed to short-header datums if it is also exposed to toasted > datums. Well the toaster doesn't run until we were about to put the tuple on disk. I was afraid there might be circumstances where data from in-memory tuples are returned and we use them without fearing them being toasted. In particular I was fearing the record/row handling in plpgsql. I was also worried about the tuples that indexes stores. But it seems they don't go through heap_form_tuple at all. It does seem that the INDEX_TOAST_HACK would need some work -- but its existence means there can't be anyone else trusting index tuples not to contain toasted data which is convenient. > I'm inclined to think that we might want to set things up so that > varlena datatypes can individually opt-in or opt-out of this treatment; > a datatype that needs alignment of its content might well wish to > opt-out to avoid copying overhead. We could do that either with a > different typlen code, or still typlen -1 but pay attention to whether > typalign is 'c'. Any reason to go with typalign? You can always use typalign='i' to get the regular headers. Alternatively, what does the trailing "a" in varlena signify? Would this be varlenb? >> Option 1) > >> We detect cases where the typmod guarantees either a fixed size or a maximum >> size < 256 bytes. > > After last week I would veto this option anyway: it fails unless we > always know typmod exactly, and I'm here to tell you we don't. Oh, heh, timing is everything I guess. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
