Re: Some regular-expression performance hacking

Joel Jacobson <joel@compiler.org>

From: "Joel Jacobson" <joel@compiler.org>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Chapman Flack" <chap@anastigmatix.net>, pgsql-hackers@lists.postgresql.org
Date: 2021-03-06T05:03:30Z
Lists: pgsql-hackers
On Fri, Feb 26, 2021, at 19:55, Tom Lane wrote:
> "Joel Jacobson" <joel@compiler.org> writes:
> > On Fri, Feb 26, 2021, at 01:16, Tom Lane wrote:
> >> 0007-smarter-regex-allocation-2.patch
> 
> > I've successfully tested this patch.
> 
> Cool, thanks for testing!

I thought it would be interesting to see if any differences
in *where* matches occur not only *what* matches.

I've compared the output from regexp_positions()
between REL_13_STABLE and HEAD.

I'm happy to report no differences were found,
except some new expected

    invalid regular expression: invalid character range

errors due to the fixes.

This time I also ran into the

    (["'`])(?:\\\1|.)*?\1

pattern due to using the flags,
which caused a timeout on REL_13_STABLE,
but the same pattern is fast on HEAD.

All good.

/Joel

Commits

  1. Suppress unnecessary regex subre nodes in a couple more cases.

  2. Improve memory management in regex compiler.

  3. Extend a test case a little

  4. Allow complemented character class escapes within regex brackets.

  5. Suppress compiler warning in new regex match-all detection code.

  6. Avoid generating extra subre tree nodes for capturing parentheses.

  7. Convert regex engine's subre tree from binary to N-ary style.

  8. Fix regex engine to suppress useless concatenation sub-REs.

  9. Recognize "match-all" NFAs within the regex engine.

  10. Invent "rainbow" arcs within the regex engine.

  11. Make some minor improvements in the regex code.

  12. Display the time when the process started waiting for the lock, in pg_locks, take 2

  13. README/C-comment: document GiST's NSN value

  14. doc: Mention NO DEPENDS ON EXTENSION in its supported ALTER commands