On Mon, 2005-03-10 at 00:37 -0400, Qingqing Zhou wrote:
Trivial patch to cleanup log_disconnections() function.
Why does the patch change behavior when
- port-remote_port is the empty string
- or, when end.tv_sec is negative
I'm not adamant that the old behavior is better, but I'd like to see
Simon Riggs [EMAIL PROTECTED] writes:
The following patch implements a fairly light set of timing statements
aimed at understanding external sort performance. There is no attempt to
alter the algorithms.
What do people think about putting something like this into 8.1?
Strictly speaking it's a
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
Sent: 03 October 2005 15:37
To: Simon Riggs
Cc: pgsql-hackers@postgresql.org; pgsql-patches@postgresql.org
Subject: Re: [PATCHES] [HACKERS] External Sort timing debug
statements
On Mon, 3 Oct 2005, Neil Conway wrote:
Why does the patch change behavior when
- port-remote_port is the empty string
Ooops, this wording change is inconsistent with Log_connections, so I
reverted it. Updated patch is attached.
- or, when end.tv_sec is negative
I can only imagine
On Mon, Oct 03, 2005 at 10:36:57AM -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
The following patch implements a fairly light set of timing
statements aimed at understanding external sort performance. There
is no attempt to alter the algorithms.
What do people think about
Simon Riggs [EMAIL PROTECTED] writes:
The following patch implements a fairly light set of timing statements
aimed at understanding external sort performance. There is no attempt to
alter the algorithms.
Minor update of patch, use this version please.
Applied with revisions: I made it use
On Mon, 2005-10-03 at 18:59 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
The following patch implements a fairly light set of timing statements
aimed at understanding external sort performance. There is no attempt to
alter the algorithms.
Minor update of patch, use this
Tom Lane [EMAIL PROTECTED] writes:
Applied with revisions: I made it use the VacRUsage code so that we
could see both CPU and elapsed time, and moved the report points around
a bit. The output with trace_sort enabled looks like this:
NOTICE: begin tuple sort: nkeys = 1, workMem = 1024,
Greg Stark [EMAIL PROTECTED] writes:
I'm not actually involved in this so maybe I'm completely off base here. But
wouldn't you want to know how many tuples are being sorted and how many data
are being written in these runs in order to be able to actually make sense of
these timing
