Re: [HACKERS] regex cache

Tom, I'm not excited about it either, but I think if we're going to make this adjustable it does need its own knob. I can easily believe that a large list of precompiled GUCs could be counterproductive given a workload where you don't get much reuse, so I don't want the list size going to the m

Re: [HACKERS] regex cache

Josh Berkus <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Hmm. Well, I still don't want to tie it to work_mem; how do you feel >> about a new GUC to determine the max number of cached REs? > Yeah. You know me, I was just trying to avoid having more GUCs. I'm not excited about it either, but

Re: [HACKERS] regex cache

Tom Lane wrote: Josh Berkus <[EMAIL PROTECTED]> writes: Having said that, I'm not sure it'd help your problem. If your query is using more than 32 regexes concurrently, it likely is using $BIGNUM regexes concurrently. How do we fix that? Hmmm. I think there's a lot of ground between 32 and

Re: [HACKERS] regex cache

Josh Berkus <[EMAIL PROTECTED]> writes: >> Having said that, I'm not sure it'd help your problem. If your query is >> using more than 32 regexes concurrently, it likely is using $BIGNUM >> regexes concurrently. How do we fix that? > Hmmm. I think there's a lot of ground between 32 and $BIGNUM.

Re: [HACKERS] regex cache

Tom, > Having said that, I'm not sure it'd help your problem. If your query is > using more than 32 regexes concurrently, it likely is using $BIGNUM > regexes concurrently. How do we fix that? Hmmm. I think there's a lot of ground between 32 and $BIGNUM. For example, where I'm hitting a wall

Re: [HACKERS] regex cache

Josh Berkus <[EMAIL PROTECTED]> writes: > I'm doing some analysis of PostgreSQL site traffic, and am being frequently > hung up by the compile-time-fixed size of our regex cache (32 regexes, per > MAX_CACHED_RES). Is there a reason why it would be hard to use work_mem > or some other dynamicall

[HACKERS] regex cache

Folks, I'm doing some analysis of PostgreSQL site traffic, and am being frequently hung up by the compile-time-fixed size of our regex cache (32 regexes, per MAX_CACHED_RES). Is there a reason why it would be hard to use work_mem or some other dynamically changeable limit for regex caching?