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.
