Re: gsoc, oprrest function for text search take 2

Поиск
Список
Период
Сортировка
От Gregory Stark
Тема Re: gsoc, oprrest function for text search take 2
Дата
Msg-id 874p5nvqv6.fsf@oxford.xeocode.com
обсуждение исходный текст
Ответ на Re: gsoc, oprrest function for text search take 2  (Jan Urbański <j.urbanski@students.mimuw.edu.pl>)
Список pgsql-hackers
Jan Urbański <j.urbanski@students.mimuw.edu.pl> writes:

> Heikki Linnakangas wrote:
>> Speaking of which, a lot of time seems to be spent on detoasting. I'd like to
>> understand that a better. Where is the detoasting coming from?
>
> Hmm, maybe bttext_pattern_cmp does some detoasting? It calls
> PG_GETARG_TEXT_PP(), which in turn calls pg_detoast_datum_packed(). Oh, and
> also I think that compare_lexeme_textfreq() uses DatumGetTextP() and that also
> does detoasting.

DatumGetTextP() will detoast packed data (ie, 1-byte length headers) whereas
DatumGetTextPP will only detoast compressed or externally stored data. I
suspect you're seeing the former.

> The root of all evil could by keeping a Datum in the TextFreq array, and not
> a "text *", which is something you pointed out earlier and I apparently
> didn't understand.

Well it doesn't really matter which type. If you store Datums which are
already detoasted then the DatumGetTextP and DatumGetTextPP will just be noops
anyways. If you store packed data (from DatumGetTextPP) then it's probably
safer to store it as Datums so if you need to pass it to any functions which
don't expect packed data they'll untoast it.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication
support!


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: WIP: patch to create explicit support for semi and anti joins
Следующее
От: Gregory Stark
Дата:
Сообщение: Re: Join Removal/ Vertical Partitioning