Re: POSIX regex performance bug in 7.3 Vs. 7.2

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>

In response to

Responses

Browse pgsql-hackers by date

  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