User-Agent: Cyrus-JMAP/3.5.0-alpha0-141-gf094924a34-fm-20210210.001-gf094924a
Mime-Version: 1.0
Message-Id: <ef5463ba-3e3c-45ec-bf02-27f91c6e09ab@www.fastmail.com>
In-Reply-To: <d8899c66-5492-43e9-8eff-a07d1d593ad0@www.fastmail.com>
References: <1340281.1613018383@sss.pgh.pa.us>
 <85140bfb-516c-449b-8a03-7930abb42b88@www.fastmail.com>
 <1813969.1613250697@sss.pgh.pa.us>
 <913516b8-c3d7-4dea-bf60-d735cf4673f1@www.fastmail.com>
 <2155152.1613358697@sss.pgh.pa.us>
 <99f6cbe0-6e58-4e41-add0-977271a5cf84@www.fastmail.com>
 <2752386.1613595636@sss.pgh.pa.us>
 <5deabab3-a335-4b57-a046-8a9ad8f2f142@www.fastmail.com>
 <12e6381c-adc1-4711-a619-864fb8df969c@www.fastmail.com>
 <2840118.1613671847@sss.pgh.pa.us>
 <d8899c66-5492-43e9-8eff-a07d1d593ad0@www.fastmail.com>
Date: Thu, 18 Feb 2021 21:44:07 +0100
From: "Joel Jacobson" <joel@compiler.org>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Some regular-expression performance hacking
Content-Type: multipart/alternative;
 boundary=cdbbcdd36abc47639ba1dc784ebd5c49
Precedence: bulk

--cdbbcdd36abc47639ba1dc784ebd5c49
Content-Type: text/plain

On Thu, Feb 18, 2021, at 20:58, Joel Jacobson wrote:
>Like you said earlier, perhaps the regex engine has been optimized enough for this time.
>If not, you want to investigate an additional idea,

In the above sentence, I meant "you _may_ want to".
I'm not at all sure these idea are applicable in the PostgreSQL regex engine,
so feel free to silently ignore these if you feel there is a risk for time waste.

>that I think can be seen as a generalization of the optimization trick for (.*),
>if I've understood how it works correctly.

Actually not sure if it can be seen as a generalization,
I just came to think of my ideas since they also improve
the case when you have lots of (.*) or bracket expressions of large ranges.

/Joel
--cdbbcdd36abc47639ba1dc784ebd5c49
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">
p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Thu, Fe=
b 18, 2021, at 20:58, Joel Jacobson wrote:<br></div><div>&gt;Like you sa=
id earlier, perhaps the regex engine has been optimized enough for this =
time.<br></div><div>&gt;If not, you want to investigate an additional id=
ea,<br></div><div><br></div><div>In the above sentence, I meant "you _ma=
y_ want to".<br></div><div>I'm not at all sure these idea are applicable=
 in the PostgreSQL regex engine,<br></div><div>so feel free to silently =
ignore these if you feel there is a risk for time waste.<br></div><div><=
br></div><div>&gt;that I think can be seen as a generalization of the op=
timization trick for (.*),<br></div><div>&gt;if I've understood how it w=
orks correctly.<br></div><div><br></div><div>Actually not sure if it can=
 be seen as a generalization,<br></div><div>I just came to think of my i=
deas since they also improve<br></div><div>the case when you have lots o=
f (.*) or bracket expressions of large ranges.<br></div><div><br></div><=
div>/Joel</div></body></html>
--cdbbcdd36abc47639ba1dc784ebd5c49--