Re: gsoc, oprrest function for text search take 2 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: gsoc, oprrest function for text search take 2
Date
Msg-id 7215.1220394464@sss.pgh.pa.us
Whole thread Raw
In response to Re: gsoc, oprrest function for text search take 2  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: gsoc, oprrest function for text search take 2
List pgsql-hackers
I wrote:
> ...  One possibly
> performance-relevant point is to use DatumGetTextPP for detoasting;
> you've already paid the costs by using VARDATA_ANY etc, so you might
> as well get the benefit.

Actually, wait a second.  That code doesn't work at all on toasted data,
because it's trying to use VARSIZE_ANY_EXHDR() before detoasting.
That would give you the physical datum size (eg the size of the toast
pointer), not the number you need.

However, this is actually not a problem because we know that the data
came from an array in pg_statistic, which means the individual members
*can't be toasted*.  At least they can't be compressed or out-of-line.
We'd do that at the array level, it's not sensible to do it on an
individual array member.

I think that right at the moment the array stuff doesn't permit short
headers either, but it would make sense to relax that someday.  So I'd
recommend that your code allow either regular or short headers, but not
worry about compression or out-of-line storage.

Which boils down to: keep using VARSIZE_ANY_EXHDR/VARDATA_ANY, but
forget the "detoasting" step.  Maybe put inAssert(!VARATT_IS_COMPRESSED(datum) && !VARATT_IS_EXTERNAL(datum))
instead.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: WIP: Column-level Privileges
Next
From: Tom Lane
Date:
Subject: Re: [PATCH] Cleanup of GUC units code