From: | Hannu Krosing <hannu(at)tm(dot)ee> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Neil Conway <neilc(at)samurai(dot)com>, Jon Jensen <jon(at)endpoint(dot)com>, wade <wade(at)wavefire(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: POSIX regex performance bug in 7.3 Vs. 7.2 |
Date: | 2003-02-05 06:06:38 |
Message-ID: | 1044425198.1612.4.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane kirjutas K, 05.02.2003 kell 01:35:
> Neil Conway <neilc(at)samurai(dot)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(at)tm(dot)ee>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-02-05 06:12:54 | Re: POSIX regex performance bug in 7.3 Vs. 7.2 |
Previous Message | Bruno Wolff III | 2003-02-05 04:00:28 | Re: PGP signing releases |