Re: Uninterruptable regexp_replace in 9.3.1 ? - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: Uninterruptable regexp_replace in 9.3.1 ?
Date
Msg-id 53077EED.2000907@2ndquadrant.com
Whole thread Raw
In response to Re: Uninterruptable regexp_replace in 9.3.1 ?  (Florian Pflug <fgp@phlo.org>)
Responses Re: Uninterruptable regexp_replace in 9.3.1 ?
Re: Uninterruptable regexp_replace in 9.3.1 ?
List pgsql-hackers
On 02/22/2014 12:04 AM, Florian Pflug wrote:
> On Feb21, 2014, at 16:46 , Craig Ringer <craig@2ndquadrant.com> wrote:
>> The real question IMO is why it's taking so long. It looks like
>> cfindloop(...) is being called multiple times, with each call taking a
>> couple of seconds.
> 
> Yeah, I wondered about this too. I've shortened the example a bit - here
> are a few observations
> 
> [snip]
>
> In other words, the observes runtime is roughly 2^i * 1.5^j for inputs
> consiting of i leading spaces (any character will probably do) followed
> by j substring of the form $X$ (X is an arbitrary character).

The biggest change in regexp support in the introduction of proper
unicode support, but that was before 9.1.

The problem report claims that the issue does not occur on 9.1, but yet:

git diff REL9_1_STABLE master  -- ./src/backend/utils/adt/regexp.c

is utterly trivial; a copyright date line change, and 1609797c which
just tweaks the includes. 9.0 has a much bigger diff.

So I'd like to confirm that this issue doesn't affect 9.1. I can
reproduce the issue againts 9.2. I don't have 9.1 or older lying around
to test against right this second.

Sandro, can you please provide the output of "SELECT version()" from a
PostgreSQL version that is not slow with this query?



(BTW, I'm highly amused by how the development style has changed around
here. From "git blame", this is from 1997:

"I haven't actually measured the speed improvement, but it `looks' a lot
quicker visually when watching regression test output."

Ha.)


-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Warning in pg_backup_archiver.c
Next
From: Craig Ringer
Date:
Subject: Re: Storing the password in .pgpass file in an encrypted format