From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Some regular-expression performance hacking |
Date: | 2021-02-23 18:05:35 |
Message-ID: | 20210223180535.ebgpwkyem33xtt7d@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2021-02-23 12:52:28 -0500, Tom Lane wrote:
> I wrote:
> > Hmph. There's an "assert(depth >= 0)" immediately in front of that,
> > so I'm not looking too kindly on the compiler thinking it's smarter
> > than I am. Do you have a suggestion on how to shut it up?
gcc can't see the assert though, in an non-cassert optimized build... If
I force assertions to be used, the warning vanishes.
> On reflection, maybe the thing to do is convert the assert into
> an always-on check, "if (depth < 0) return false". The assertion
> is essentially saying that there's no arc leading directly from
> the pre state to the post state. Which there had better not be,
> or a lot of other stuff is going to go wrong; but I suppose there's
> no way to explain that to gcc. 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.
I have been wondering about making Asserts do something along those
lines - but it'd need to be opt-in, since we clearly have a lot of
assertions that would cost too much.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-02-23 18:09:18 | Re: Some regular-expression performance hacking |
Previous Message | Tom Lane | 2021-02-23 17:52:28 | Re: Some regular-expression performance hacking |