On 2013-02-20 10:16:45 -0500, Robert Haas wrote: > On Tue, Feb 19, 2013 at 9:26 AM, Andres Freund <and...@2ndquadrant.com> wrote: > > On 2013-02-19 09:12:02 -0500, Robert Haas wrote: > >> On Tue, Feb 19, 2013 at 9:00 AM, Andres Freund <and...@2ndquadrant.com> > >> wrote: > >> >> I'd be a little > >> >> reluctant to do it the way you propose because we might, at some > >> >> point, want to try to reduce the size of toast pointers. If you have > >> >> a tuple with many attributes, the size of the TOAST pointers > >> >> themselves starts to add up. It would be nice to be able to have 8 > >> >> byte or even 4 byte toast pointers to handle those situations. If we > >> >> steal one or both of those lengths to mean "the data is cached in > >> >> memory somewhere" then we can't use those lengths in a smaller on-disk > >> >> representation, which would seem a shame. > >> > > >> > I agree. As I said above, having the type overlayed into the lenght was > >> > and is a bad idea, I just haven't found a better one thats compatible > >> > yet. > >> > Except inventing typlen=-3 aka "toast2" or something. But even that > >> > wouldn't help getting rid of existing pg_upgraded tables. Besides being > >> > a maintenance nightmare. > >> > > >> > The only reasonable thing I can see us doing is renaming > >> > varattrib_1b_e.va_len_1be into va_type and redefine VARSIZE_1B_E into a > >> > switch that maps types into lengths. But I think I would put this off, > >> > except placing a comment somewhere, until its gets necessary. > >> > >> I guess I wonder how hard we think it would be to insert such a thing > >> when it becomes necessary. How much stuff is there out there that > >> cares about the fact that that length is a byte? > > > > You mean whether we could store the length in 6 bytes and use two for > > the type? That should probably work as well. But I don't see much > > advantage in that given that all those sizes ought to be static. > > Redefining VARSIZE_1B_E as indicated above should be fairly easy, there > > aren't many callsites that touch stuff at such low level. > > /me blinks. > > No, that's not what I meant. I meant: how hard it would be to > redefine VARSIZE_1B_E along the lines you suggest?
Should be pretty easy. Will do so for the next revision. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers