|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Jan Urbański <j(dot)urbanski(at)students(dot)mimuw(dot)edu(dot)pl>, 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|
> ... 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))
regards, tom lane
|Next Message||Tom Lane||2008-09-02 22:36:40||Re: [PATCH] Cleanup of GUC units code|
|Previous Message||Stephen Frost||2008-09-02 22:18:23||Re: WIP: Column-level Privileges|