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 measure
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 = 10
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 pa
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 i
