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  (Andres Freund <andres@anarazel.de>)
Re: BUG #16241: Degraded hash join performance  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: BUG #16241: Degraded hash join performance
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #16243: non super user take pg_restore found some errors.