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
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 |