Re: POSIX regex performance bug in 7.3 Vs. 7.2

Поиск
Список
Период
Сортировка
От Hannu Krosing
Тема Re: POSIX regex performance bug in 7.3 Vs. 7.2
Дата
Msg-id 1044425198.1612.4.camel@localhost.localdomain
обсуждение исходный текст
Ответ на Re: POSIX regex performance bug in 7.3 Vs. 7.2  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: POSIX regex performance bug in 7.3 Vs. 7.2  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane kirjutas K, 05.02.2003 kell 01:35:
> Neil Conway <neilc@samurai.com> writes:
> > Speaking of which, is there (or should there be) some mechanism for
> > increasing the size of the compiled pattern cache? Perhaps a GUC var?
> 
> I thought about that while I was messing with the code, but I don't
> think there's much point in it, unless someone wants to invest the work
> to make the cache search much smarter (maybe a hash table?).  At present
> a larger cache will cost you in extra search time, especially in the
> case where the pattern isn't in the cache.
> 
> I did do the work last night to convert the cache management algorithm
> into a self-organizing list (a la Knuth) rather than a round-robin
> search as it was before.  This should reduce the expected number of
> comparisons for cases where the cache is actually accomplishing
> something, but of course it's no help if you have too many patterns
> for the cache.

Perhaps the decision weather to try to use the cache at all could be
done at planning time depending on statistics information ?

Another idea is to make special regex type and store the regexes
pre-parsed (i.e. in some fast-load form) ?

-- 
Hannu Krosing <hannu@tm.ee>


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

Предыдущее
От: Bruno Wolff III
Дата:
Сообщение: Re: PGP signing releases
Следующее
От: Tom Lane
Дата:
Сообщение: Re: POSIX regex performance bug in 7.3 Vs. 7.2