Skip site navigation (1) Skip section navigation (2)

Re: Something's been bugging me

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: "PostgreSQL-development Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Something's been bugging me
Date: 2007-09-29 16:21:07
Message-ID: 4709.1191082867@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> I'm not for this because it would complicate the already-too-complicated
>> inner-loop tests for deciding which form of datum you're looking at.
>> 
>> The idea that I recall mentioning was to expend another byte in TOAST
>> pointers to make them self-identifying, ie, instead of 0x80 or 0x01
>> signaling something that *must* be a 17-byte toast pointer, that bit
>> pattern signals "something else" and the content of the next byte
>> lets you know what.  So TOAST pointers would take 18 bytes instead of
>> 17, and there would be room for additions of other sorts of pointers.

> Hm, wouldn't that be just as expensive though?

No, I don't think so, because it'd be a second-level test that's only
hit after determining that you have a 1B_E kind of datum.  Furthermore,
it'd only be hit if you were actually trying to determing the datum's
value, and not if (for instance) you only wanted to skip past it to the
next field.

> You would still have to look at
> the next byte and check it against various values to see what length to skip
> over. Hm, unless we put the length in the following byte.

Making the second byte contain the length would work well for the sorts
of cases I was envisioning, which was different sorts of fixed-size
pointer-ish objects.  I suppose it would not scale well towards having a
different kind of inline compression method, but I don't see how your
proposal handles that either.

After a bit of reflection, I'd argue that variant inline compression
methods ought to be implemented within the 4B_C family of datum
representations.  It looks to me like we have a couple of leftover bits
within that, because va_rawsize can't exceed 1G, and so there is room
to include two flag bits in it.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Gregory StarkDate: 2007-09-29 16:22:54
Subject: Re: Something's been bugging me
Previous:From: Andrew DunstanDate: 2007-09-29 15:42:40
Subject: Re: PGBuildfarm member skylark Branch HEAD Failed at Stage Make

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group