Re: [PATCHES] External Sort timing debug statements

2005-10-03 Thread Tom Lane
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 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, randomAccess = t
NOTICE:  switching to external sort: CPU 0.05s/0.10u sec elapsed 0.15 sec
NOTICE:  finished writing run 1: CPU 0.14s/0.83u sec elapsed 0.99 sec
NOTICE:  finished writing run 2: CPU 0.25s/1.67u sec elapsed 1.94 sec
NOTICE:  finished writing run 3: CPU 0.37s/2.51u sec elapsed 2.90 sec
NOTICE:  finished writing run 4: CPU 0.48s/3.36u sec elapsed 3.86 sec
...
NOTICE:  finished writing run 45: CPU 5.06s/38.26u sec elapsed 43.55 sec
NOTICE:  performsort starting: CPU 5.10s/38.62u sec elapsed 43.95 sec
NOTICE:  finished writing run 46: CPU 5.11s/38.84u sec elapsed 44.18 sec
NOTICE:  finished writing final run 47: CPU 5.11s/38.88u sec elapsed 44.22 sec
NOTICE:  finished merge step: CPU 5.12s/39.02u sec elapsed 44.37 sec
NOTICE:  finished merge step: CPU 5.13s/39.16u sec elapsed 44.53 sec
...
NOTICE:  finished merge step: CPU 6.57s/67.78u sec elapsed 74.83 sec
NOTICE:  performsort done: CPU 6.57s/67.78u sec elapsed 74.84 sec
NOTICE:  sort ended: CPU 10.80s/74.73u sec elapsed 86.21 sec

regards, tom lane

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: [PATCHES] External Sort timing debug statements

2005-10-03 Thread Simon Riggs
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 version please.
 
 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, randomAccess = t
 NOTICE:  switching to external sort: CPU 0.05s/0.10u sec elapsed 0.15 sec
 NOTICE:  finished writing run 1: CPU 0.14s/0.83u sec elapsed 0.99 sec
 NOTICE:  finished writing run 2: CPU 0.25s/1.67u sec elapsed 1.94 sec
 NOTICE:  finished writing run 3: CPU 0.37s/2.51u sec elapsed 2.90 sec
 NOTICE:  finished writing run 4: CPU 0.48s/3.36u sec elapsed 3.86 sec
 ...
 NOTICE:  finished writing run 45: CPU 5.06s/38.26u sec elapsed 43.55 sec
 NOTICE:  performsort starting: CPU 5.10s/38.62u sec elapsed 43.95 sec
 NOTICE:  finished writing run 46: CPU 5.11s/38.84u sec elapsed 44.18 sec
 NOTICE:  finished writing final run 47: CPU 5.11s/38.88u sec elapsed 44.22 sec
 NOTICE:  finished merge step: CPU 5.12s/39.02u sec elapsed 44.37 sec
 NOTICE:  finished merge step: CPU 5.13s/39.16u sec elapsed 44.53 sec
 ...
 NOTICE:  finished merge step: CPU 6.57s/67.78u sec elapsed 74.83 sec
 NOTICE:  performsort done: CPU 6.57s/67.78u sec elapsed 74.84 sec
 NOTICE:  sort ended: CPU 10.80s/74.73u sec elapsed 86.21 sec

Many thanks,

Best Regards, Simon Riggs


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


Re: [PATCHES] External Sort timing debug statements

2005-10-02 Thread Simon Riggs
On Sun, 2005-10-02 at 19:43 +0100, Simon Riggs wrote:
 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.

 Best Regards, Simon Riggs
Index: src/backend/utils/misc/guc.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/misc/guc.c,v
retrieving revision 1.289
diff -c -c -r1.289 guc.c
*** src/backend/utils/misc/guc.c	24 Sep 2005 22:54:39 -	1.289
--- src/backend/utils/misc/guc.c	2 Oct 2005 19:58:02 -
***
*** 92,97 
--- 92,98 
  extern int	CommitSiblings;
  extern char *default_tablespace;
  extern bool	fullPageWrites;
+ extern bool debug_sort;
  
  static const char *assign_log_destination(const char *value,
  	   bool doit, GucSource source);
***
*** 764,770 
  		false, NULL, NULL
  	},
  #endif
! 
  	{
  		{log_hostname, PGC_SIGHUP, LOGGING_WHAT,
  			gettext_noop(Logs the host name in the connection logs.),
--- 765,779 
  		false, NULL, NULL
  	},
  #endif
! 	{
! 		{debug_sort, PGC_USERSET, DEVELOPER_OPTIONS,
! 			gettext_noop(no description available),
! 			NULL,
! 			GUC_NOT_IN_SAMPLE
! 		},
! 		debug_sort,
! 		false, NULL, NULL
! 	},
  	{
  		{log_hostname, PGC_SIGHUP, LOGGING_WHAT,
  			gettext_noop(Logs the host name in the connection logs.),
Index: src/backend/utils/sort/tuplesort.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/sort/tuplesort.c,v
retrieving revision 1.50
diff -c -c -r1.50 tuplesort.c
*** src/backend/utils/sort/tuplesort.c	23 Sep 2005 15:36:57 -	1.50
--- src/backend/utils/sort/tuplesort.c	2 Oct 2005 19:58:02 -
***
*** 85,90 
--- 85,92 
  
  #include postgres.h
  
+ #include sys/time.h
+ 
  #include access/heapam.h
  #include access/nbtree.h
  #include catalog/pg_amop.h
***
*** 394,399 
--- 396,404 
   */
  static Tuplesortstate *qsort_tuplesortstate;
  
+ /* debug variables */
+ bool debug_sort = false;
+ struct timeval start_t, current_t;
  
  /*
   *		tuplesort_begin_xxx
***
*** 422,427 
--- 427,439 
  
  	state = (Tuplesortstate *) palloc0(sizeof(Tuplesortstate));
  
+ if (debug_sort)
+ 	{
+ 	ereport(NOTICE,
+ 			(errmsg(tuplesort begin  work_mem= %u, workMem)));
+	gettimeofday(start_t, NULL);
+ }
+ 
  	state-status = TSS_INITIAL;
  	state-randomAccess = randomAccess;
  	state-availMem = workMem * 1024L;
***
*** 454,459 
--- 466,475 
  	Tuplesortstate *state = tuplesort_begin_common(workMem, randomAccess);
  	int			i;
  
+ if (debug_sort)
+ 		ereport(NOTICE,
+ 			(errmsg(+0 secs  heap sort  nkeys= %u, nkeys)));
+ 
  	AssertArg(nkeys  0);
  
  	state-comparetup = comparetup_heap;
***
*** 499,504 
--- 515,524 
  {
  	Tuplesortstate *state = tuplesort_begin_common(workMem, randomAccess);
  
+ if (debug_sort)
+ 		ereport(NOTICE,
+ 			(errmsg(+0 secs  index sort)));
+ 
  	state-comparetup = comparetup_index;
  	state-copytup = copytup_index;
  	state-writetup = writetup_index;
***
*** 666,671 
--- 686,698 
  			/*
  			 * Nope; time to switch to tape-based operation.
  			 */
+ if (debug_sort)
+ {
+		gettimeofday(current_t, NULL);
+ 		ereport(NOTICE,
+ 			(errmsg(+%ld secs  switching to external sort, 
+ 	(long) (current_t.tv_sec - start_t.tv_sec;
+ }
  			inittapes(state);
  
  			/*
***
*** 1042,1047 
--- 1069,1082 
  	int			j;
  	int			a;
  
+ if (debug_sort)
+ {
+		gettimeofday(current_t, NULL);
+ 		ereport(NOTICE,
+ 			(errmsg(+%ld secs  starting build of next run, 
+ 	(long) (current_t.tv_sec - start_t.tv_sec;
+ }
+ 
  	/* Step D3: advance j (destTape) */
  	if (state-tp_dummy[state-destTape]  state-tp_dummy[state-destTape + 1])
  	{
***
*** 1082,1087 
--- 1117,1131 
  	Assert(state-status == TSS_BUILDRUNS);
  	Assert(state-memtupcount == 0);
  
+ if (debug_sort)
+ {
+		gettimeofday(current_t, NULL);
+ 		ereport(NOTICE,
+ 			(errmsg(+%ld secs  run building complete  nruns= %u, 
+ 	(long) (current_t.tv_sec - start_t.tv_sec),
+ state-currentRun)));
+ }
+ 
  	/*
  	 * If we produced only one initial run (quite likely if the total data
  	 * volume is between 1X and 2X workMem), we can just use that tape as
***
*** 1093,1100 
--- 1137,1158 
  		/* must freeze and rewind the finished output tape */
  		LogicalTapeFreeze(state-tapeset, state-result_tape);
  		state-status = TSS_SORTEDONTAPE;
+ if (debug_sort)
+ {
+		gettimeofday(current_t, NULL);
+		ereport(NOTICE,
+			(errmsg(+%ld secs  no final merge required, 
+	(long)