Re: Fixed length data types issue - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Fixed length data types issue
Date
Msg-id 871wqjtf21.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: Fixed length data types issue  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Fixed length data types issue  (Bruce Momjian <bruce@momjian.us>)
Re: Fixed length data types issue  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

> Bruce Momjian <bruce@momjian.us> writes:
> > Tom Lane wrote:
> >> Either way, I think it would be interesting to consider
> >> 
> >> (a) length word either one or two bytes, not four.  You can't need more
> >> than 2 bytes for a datum that fits in a disk page ...
> 
> > That is an interesting observation, though could compressed inline
> > values exceed two bytes?
> 
> After expansion, perhaps, but it's the on-disk footprint that concerns
> us here.

I'm a bit confused by this and how it would be handled in your sketch. I
assumed we needed a bit pattern dedicated to 4-byte length headers because
even though it would never occur on disk it would be necessary to for the
uncompressed and/or detoasted data.

In your scheme what would PG_GETARG_TEXT() give you if the data was detoasted
to larger than 16k?

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Kevin Brown
Date:
Subject: Re: Foreign keys
Next
From: Bruce Momjian
Date:
Subject: Re: Fixed length data types issue