Re: BUG #16241: Degraded hash join performance - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #16241: Degraded hash join performance
Date
Msg-id 6089.1580832029@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #16241: Degraded hash join performance  (Andres Freund <andres@anarazel.de>)
Responses Re: BUG #16241: Degraded hash join performance  (Andres Freund <andres@anarazel.de>)
Re: BUG #16241: Degraded hash join performance  (Andres Freund <andres@anarazel.de>)
List pgsql-bugs
Andres Freund <andres@anarazel.de> writes:
> Interesting! The no-children one clearly shows that a lot of the the
> time is spent evaluating regular expressions (there's other regex
> functions in the profile too):
>     23.36%  postgres  postgres            [.] subcolor

Huh ...

> I'm not aware of any relevant regular expression evaluation changes
> between 11 and 12. Tom, does this trigger anything?

(1) Nope, I'm not either; the last non-back-patched change in that
code was c54159d44 in v10.

(2) subcolor() is part of regex compilation, not execution, which makes
one wonder why it's showing up at all.  Maybe the regex cache in
adt/regexp.c is overflowing and preventing useful caching?  But
that didn't change in v12 either.  Are these test cases really
100% equivalent?  I'm wondering if there are a few more "hot"
regex patterns in the v12 data ...

(3) Where the heck is the regex use coming from at all?  I don't
see any regex operators in the plan.  Maybe it's inside the
plpgsql function?

            regards, tom lane



pgsql-bugs by date:

Previous
From: Andres Freund
Date:
Subject: Re: BUG #16241: Degraded hash join performance
Next
From: Tom Lane
Date:
Subject: Re: BUG #16243: non super user take pg_restore found some errors.