Merlin Moncure <[email protected]> writes:
> Bisecting revealed the obvious culprit:
> 112faf1378ee: Log remote NOTICE, WARNING, and similar messages using
> ereport().
> The commit solves an obvious problem, and I do not think it should be
> reverted. This does raise a couple of questions, however:
> * Is it really true that ereport() is up to 20x slower than stderr?
> * Why does stderr have such wierd performance variations?
I did a simple performance test, measuring tight loops around
ereport(LOG,
errmsg_internal("%s", my_string));
and
fprintf(stderr, "%s\n", my_string);
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?
> * 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.
regards, tom lane
