Horton

Re: Another regexp performance improvement: skip useless paren-captures

Mark Dilger <mark.dilger@enterprisedb.com>

View thread View on postgr.es
From: Mark Dilger <mark.dilger@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Dunstan <andrew@dunslane.net>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Joel Jacobson <joel@compiler.org>
Date: 2021-08-10T01:17:40Z
Lists: pgsql-hackers 

> On Aug 9, 2021, at 6:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 
> Hm.  I'm not sure that this example proves anything about Perl's handling
> of the situation, since you didn't use a backref.

Well, this doesn't die either:

if ('foo' =~ m/((??{ die; })(.)(??{ die $1; })){0}((??{ die "got here"; })|\2)/)
{
    print "matched\n";
}

The point is that the regex engine never walks the part of the pattern that {0} qualifies.  I thought it was more clear in the prior example, because that example proves that the engine does get as far as capturing.  This example also does that, and with a backref, because it dies with "got here".
 
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Commits

  1. Fix regexp misbehavior with capturing parens inside "{0}".

  2. Let regexp_replace() make use of REG_NOSUB when feasible.

  3. Fix bogus assertion in BootstrapModeMain().

  4. Avoid determining regexp subexpression matches, when possible.

  5. Check the size in COPY_POINTER_FIELD

  6. Make regexp engine's backref-related compilation state more bulletproof.