To: Achilleas Mantzios <achill@matrix.gatewaynet.com>
cc: pgsql-performance@postgresql.org
Subject: Re: syslog performance when logging big statements 
In-reply-to: <200807081821.57935.achill@matrix.gatewaynet.com> 
References: <200807081524.47366.achill@matrix.gatewaynet.com>
	<8675.1215527716@sss.pgh.pa.us>
	<200807081821.57935.achill@matrix.gatewaynet.com>
Comments: In-reply-to Achilleas Mantzios <achill@matrix.gatewaynet.com>
	message dated "Tue, 08 Jul 2008 18:21:57 +0300"
Date: Tue, 08 Jul 2008 14:34:01 -0400
Message-ID: <12596.1215542041@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Achilleas Mantzios <achill@matrix.gatewaynet.com> writes:
> Στις Tuesday 08 July 2008 17:35:16 ο/η Tom Lane έγραψε:
>> Hmm.  There's a function in elog.c that breaks log messages into chunks
>> for syslog.  I don't think anyone's ever looked hard at its performance
>> --- maybe there's an O(N^2) behavior?

> Thanx,
> i changed PG_SYSLOG_LIMIT in elog.c:1269 from 128 to 1048576
> and i got super fast stderr performance. :)

Doesn't seem like a very good solution given its impact on the stack
depth right there.

Looking at the code, the only bit that looks like repeated work are the
repeated calls to strchr(), which would not be an issue in the "typical"
case where the very long message contains reasonably frequent newlines.
Am I right in guessing that your problematic statement contained
megabytes worth of text with nary a newline?

If so, we can certainly fix it by arranging to remember the last
strchr() result across loop iterations, but I'd like to confirm the
theory before doing that work.

			regards, tom lane