Re: POSIX regex performance bug in 7.3 Vs. 7.2 - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: POSIX regex performance bug in 7.3 Vs. 7.2
Date
Msg-id 1044425198.1612.4.camel@localhost.localdomain
Whole thread Raw
In response to Re: POSIX regex performance bug in 7.3 Vs. 7.2  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: POSIX regex performance bug in 7.3 Vs. 7.2
List 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 by date:

Previous
From: Bruno Wolff III
Date:
Subject: Re: PGP signing releases
Next
From: Tom Lane
Date:
Subject: Re: POSIX regex performance bug in 7.3 Vs. 7.2