Vadim Mikheev <vadim@krs.ru> writes:
> Note: I told about "multi-representation" feature, not just about
> LO/CLOBS/BLOBS support. "Multi-representation" means that server
> stores tuple fields sometime inside the main relation file,
> sometime outside of it, but this is hidden from user and so
> people "just put their data into tuples". I think that putting
> big fields outside of main relation file is very good thing.
Ah, I see what you mean. If you think that is easier than splitting
tuples, we could go that way. We'd have a limit of about 500 fields in
a tuple (maybe less if the tuple contains "small" fields that are not
pushed to another place). That's annoying if the goal is to eliminate
limits, but I think it would be unlikely to be a big problem in
practice.
Perhaps a better way is to imagine these "pointers to another place"
to be just part of the tuple structure on disk, without tying them to
individual fields. In other words, the tuple's data is still a string
of fields, but now you can have that data either right there with the
tuple header, or pointed to by a list of "indirect links" that are
stored with the tuple header. (Kinda like direct vs indirect blocks in
Unix filesystem.) You can chop the tuple data into blocks without
regard for field boundaries if you do it that way. I think that might
be better than altering the definition of varlena --- it'd be visible
only to the tuple read and write mechanisms, not to everything in the
executor that deals with varlena fields...
regards, tom lane