Re: Up to 50x degradation in dblink performance when receiving notice traffic 19 vs 18

On Tue, Sep 22, 2026 at 2:31 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
>
For me, ereport is consistently about 3x slower than fprintf
> when using bare log-to-a-file (logging_collector off), or about
> 2x slower when using the logging collector with default options.
> That's more or less in line with what I'd expect. So there's
> something odd going on in your setup; where is log output going
> exactly?
>

Hm, this might be an architecture-specific issue. Try running this
https://pastebin.com/W4snReJh against stock pg18 and pg19 (except for
dblink compiled in). I'm running on a capable Mac laptop. If you
reproduce it, I suspect you might find the pg18 behavior more interesting
(I'm guessing something related to flushed output).

> > * Why does dblink even bother with NOTICE level messages at all? They
> are
> > not produced at all to the receiving client, only to the hosting database
> > log (which IMO is very non-intuitive).
>
> I think the intent of 112faf137 was to get log message prefixes
> attached to these messages without disturbing the pre-existing
> behavior about what gets recorded where. Maybe there's room for
> a discussion about changing that, but since postgres_fdw has been
> acting like that for a long time it might be a hard sell.
>

Right... I guess proposing a dblink specific note in the docs that
describes how remote query client messages are composed in the server log,
and the very unintuitive workaround to pass the GUC setting in the
connection string. The existing behavior is perhaps not very good but it
has been in place for quite some time, so I agree.

merlin