Re: Short varlena headers and arrays

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "PostgreSQL Development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Short varlena headers and arrays
Date: 2007-02-19 18:34:17
Message-ID: 87ps86ngie.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> Once this is done it may be worth having arrays convert to short varlenas as
>> well.
>
> Elements of arrays are not subject to being toasted by themselves, so
> I don't think you can make that work. At least not without breaking
> wide swaths of code that works fine today.

You think it's more likely there are places that build arrays and then read
the items back without passing through detoast than there are places that
build tuples and do so?

Btw I ran into some problems with system tables. Since many of them are read
using the GETSTRUCT method and in that method the first varlena field should
be safely accessible, i would have to not skip the alignment for the first
varlena field in system tables. Instead I just punt on all system tables. The
only one that seems like it'll be loss on is pg_statistic and there the
biggest problem is the space wasted inside the arrays, not before the varlena
fields.

Also, int2vector and oidvector don't expect to be toasted so I've skipped them
as well. If we want to have an escape hatch they would have to be so marked.
For now I just hard coded them.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2007-02-19 18:34:55 Re: Multiple Storage per Tablespace, or Volumes
Previous Message Peter Eisentraut 2007-02-19 18:30:21 Re: pg_proc without oid?