Re: Making aggregate deserialization (and WAL receive) functions slightly faster
От | David Rowley |
---|---|
Тема | Re: Making aggregate deserialization (and WAL receive) functions slightly faster |
Дата | |
Msg-id | CAApHDvpUGzJSPkWTJfOn_5bwbzA=yHjMmSLHfbYoBjrB4eji4g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Making aggregate deserialization (and WAL receive) functions slightly faster (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Making aggregate deserialization (and WAL receive) functions slightly faster
|
Список | pgsql-hackers |
On Mon, 30 Oct 2023 at 23:48, Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Fri, Oct 27, 2023 at 3:23 AM David Rowley <dgrowleyml@gmail.com> wrote: > > * parallel.c in HandleParallelMessages(): > > * applyparallelworker.c in HandleParallelApplyMessages(): > > Both the above calls are used to handle ERROR/NOTICE messages from > parallel workers as you have also noticed. The comment atop > initReadOnlyStringInfo() clearly states that it is used in the > performance-critical path. So, is it worth changing these places? In > the future, this may pose the risk of this API being used > inconsistently. I'm ok to leave those ones out. But just a note on the performance side, if we go around needlessly doing palloc/memcpy then we'll be flushing possibly useful cachelines out and cause slowdowns elsewhere. That's a pretty hard thing to quantify, but something to keep in mind. David
В списке pgsql-hackers по дате отправления: