Re: [RFC] indirect toast tuple support - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [RFC] indirect toast tuple support
Date
Msg-id 20130220151901.GB5668@awork2.anarazel.de
Whole thread Raw
In response to Re: [RFC] indirect toast tuple support  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 2013-02-20 10:16:45 -0500, Robert Haas wrote:
> On Tue, Feb 19, 2013 at 9:26 AM, Andres Freund <andres@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 <andres@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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [RFC] indirect toast tuple support
Next
From: Kevin Grittner
Date:
Subject: Re: Materialized views WIP patch