Re: BUG #16241: Degraded hash join performance

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Thomas Butz <tbutz(at)optitool(dot)de>, pgsql-bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #16241: Degraded hash join performance
Date: 2020-02-04 16:00:29
Message-ID: 6089.1580832029@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2020-02-04 16:27:38 Re: BUG #16243: non super user take pg_restore found some errors.
Previous Message Andres Freund 2020-02-04 15:01:52 Re: BUG #16241: Degraded hash join performance