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

Re: Packed short varlenas, what next?

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: Packed short varlenas, what next?
Date: 2007-03-01 09:15:04
Message-ID: 87zm6xs4tj.fsf@stark.xeocode.com (view raw or flat)
Thread:
Lists: pgsql-hackers
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> I've disabled packed varlenas for user-defined data types and find tsearch2
>> and _int still fail. tsearch2 requires the small patch attached. _int seems to
>> be unrelated.
>
> As of when?  I committed fixes earlier tonight that seem to handle the
> case of VARSIZE-is-ntohl.
>
> The patch you suggest is orthogonal to what I did; it looks like it
> might be right, but regression passes without it, so what was your test
> case that led you to it?

I'm running the regression tests with the full packed varlena changes except
that I've modified it not to pack user defined data types (typid >
FirstNormalObjectId). So all varlenas need to go through detoast_datum if they
come out of a heatuple even if (especially if) they used to be too small to be
toasted.

In fact I think the line I posted is actually a bug anyways. I'm unclear what
the text field it's fetching represents and maybe it's usually small, but it
looks like there's nothing stopping it from being large enough to be toasted
in theory.

To get tsearch et al to work with packed varlena headers without disabling
them for user defined data types will require a lot more detoast_datum calls
throughout the gist data types (or defining proper GETARG macros for them).

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

In response to

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2007-03-01 09:21:58
Subject: Re: Postgres Replication
Previous:From: Simon RiggsDate: 2007-03-01 09:09:01
Subject: Re: VACUUM and spoiling the buffer manager cache

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