Re: Another regexp performance improvement: skip useless paren-captures
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: pgsql-hackers@lists.postgresql.org, Joel Jacobson <joel@compiler.org>
Date: 2021-08-05T14:36:21Z
Lists: pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes: > I'm a bit worried about how you'll keep track of back-ref numbering > since back-refs only count capturing groups, and you're silently turning > a capturing group into a non-capturing group. They're already numbered at this point, and we aren't changing the numbers of the capturing groups that remain live. There will be unused entries in the regmatch_t array at runtime (corresponding to the zapped groups), but that doesn't cost anything worth mentioning. Now that you mention it, I am not sure whether there are any regression test cases that specifically cover still being able to match \2 when the first capture group went away. Probably should add more cases... regards, tom lane
Commits
-
Fix regexp misbehavior with capturing parens inside "{0}".
- 92620e82f6a1 12.9 landed
- 7e75fe390b68 9.6.24 landed
- 3ebd32e70c09 11.14 landed
- 244dd79923a1 14.0 landed
- 071146184a59 13.5 landed
- 062c4c791937 10.19 landed
- 65dc30ced64c 15.0 landed
-
Let regexp_replace() make use of REG_NOSUB when feasible.
- 18bac60ede44 15.0 landed
-
Fix bogus assertion in BootstrapModeMain().
- e12694523e7e 15.0 cited
-
Avoid determining regexp subexpression matches, when possible.
- 0e6aa8747d43 15.0 landed
-
Check the size in COPY_POINTER_FIELD
- c1132aae336c 15.0 cited
-
Make regexp engine's backref-related compilation state more bulletproof.
- cb76fbd7ec87 15.0 cited