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.

Each major point in the algorithms is marked as shown in this example:

postgres=# set debug_sort=true;
SET

postgres=# explain analyze select * from test2 order by col1,col2;

NOTICE: tuplesort begin work_mem= 1024
NOTICE: +0 secs heap sort nkeys= 2
NOTICE: +0 secs switching to external sort
NOTICE: +1129 secs starting build of next run
NOTICE: +2229 secs run building complete nruns= 2
NOTICE: +2229 secs merging runs with 6 tapes

....

NOTICE: +3036 secs starting final merge

I'll add other information, as requested.

The "6 tapes" is currently hardcoded, though is included in expectation
of implementing variable numbers of tapes.

I'm not sure if I got the header file correct for full portability of
gettimeofday(). Please correct me, if this is the case.

Please post sort performance data back via this post.

Best Regards, Simon Riggs


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

I'm not averse to it. I think it's a good option and I support trace_sort
(it really is more of a trace).

On 10/3/05, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Simon Riggs <simon@2ndquadrant.com> 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 new feature, but the patch seems pretty
> noninvasive, and we'd be much more likely to get data points if the
> code exists in the mainline release than if people have to patch
> their copies.
>
> > postgres=# set debug_sort=true;
>
> I'm a bit inclined to call it trace_sort instead, and to document it
> under "Developer Options". Comments?
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>



--
Respectfully,

Jonah H. Harris, Database Internals Architect
EnterpriseDB Corporation
http://www.enterprisedb.com/