Horton

Re: Some regular-expression performance hacking

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2021-02-23T18:22:35Z
Lists: pgsql-hackers 
Andres Freund <andres@anarazel.de> writes:
> On 2021-02-23 12:52:28 -0500, Tom Lane wrote:
>> ... It is annoying to have to expend
>> an always-on check for a can't-happen case, though.

> Wouldn't quite work like that because of the restrictions of what pg
> infrastructure we want to expose the regex engine to, but a
>     if (depth < 0)
>         pg_unreachable();
> would avoid the runtime overhead and does fix the warning.

Yeah, I still have dreams of someday converting the regex engine
into an independent project, so I don't want to make it depend on
pg_unreachable.  I'll put in the low-tech fix.

			regards, tom lane

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