Re: gsoc, oprrest function for text search take 2

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

> 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 in
> Assert(!VARATT_IS_COMPRESSED(datum) && !VARATT_IS_EXTERNAL(datum))
> instead.

Tom, Heikki, everyone,

just to let you know - I haven't forgot about this, but right now I'm
porting myself to another country, so things are quite hectic ;)

I'll pick up the patch in a couple of weeks, so I'm sure it will be
ready for the November CF.

Thanks,
Jan