|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Postgres - Hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: gsoc, oprrest function for text search take 2|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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))
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.
|Next Message||Zdenek Kotala||2008-09-19 08:52:12||Re: Where to Host Project|
|Previous Message||Bernt Drange||2008-09-19 08:26:44||Re: Regaining superuser access|