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
|
Список | 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 по дате отправления: