From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jan Wieck <JanWieck(at)yahoo(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: TOAST vs arrays |
Date: | 2000-07-18 14:43:47 |
Message-ID: | 17808.963931427@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
JanWieck(at)t-online(dot)de (Jan Wieck) writes:
>> What do you want to do about this? We could have heap_tuple_toast_attrs
>> scan through all the elements of arrays of toastable types, but that
>> strikes me as slow. I'm thinking the best approach is for the array
>> construction routines to refuse to insert toasted values into array
>> objects in the first place --- instead, expand them before insertion.
>> Then the whole array could be treated as a toastable object, but there
>> are no references inside the array to worry about.
> I think the array construction routines is the right place to
> expand them.
Sounds like a plan.
Just in case anyone wants to object: I'm planning to rip out all of
the "large object array" and "chunked array" support that's in there
now. AFAICS it does nothing that won't be done as well or better by
toasted arrays, and it probably doesn't work anyway (seeing that much
of it has been ifdef'd out for a long time).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-07-18 14:52:20 | Re: Untrusted PL/Tcl? |
Previous Message | Magnus Hagander | 2000-07-18 13:59:44 | FlushRelationBuffers returned -2 |