Re: BUG #16241: Degraded hash join performance
От | Tom Lane |
---|---|
Тема | Re: BUG #16241: Degraded hash join performance |
Дата | |
Msg-id | 6089.1580832029@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #16241: Degraded hash join performance (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: BUG #16241: Degraded hash join performance
Re: BUG #16241: Degraded hash join performance |
Список | 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 по дате отправления: