Re: [PATCHES] Fix for log_executor_stats

2004-03-04 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes:
 it only logs executor stats for PORTAL_MULTI_QUERY queries.  I assume
 this was done so that individual queries are logged rather than the
 entire multi-query.

I think it was just an oversight.  IIRC, the PORTAL_MULTI_QUERY path of
control is the only one that has direct predecessor code in pre-7.4
releases.  I probably missed the need to add stats code to the new code
paths.

Are you sure that log_executor_stats is the only missing case?

Also, I am not sure that the code paths for extended query messages
are doing logging correctly.  I recall being worried about how to
translate the logging definitions into situations where parsing and
execution are separate, or where a statement may be partially executed
and then we come back for more.  I didn't have time in the 7.4 cycle to
really think about it, but someone should take a look.

regards, tom lane

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match


Re: [PATCHES] Fix for log_executor_stats

2004-03-04 Thread Bruce Momjian
Tom Lane wrote:
 Bruce Momjian [EMAIL PROTECTED] writes:
  it only logs executor stats for PORTAL_MULTI_QUERY queries.  I assume
  this was done so that individual queries are logged rather than the
  entire multi-query.
 
 I think it was just an oversight.  IIRC, the PORTAL_MULTI_QUERY path of
 control is the only one that has direct predecessor code in pre-7.4
 releases.  I probably missed the need to add stats code to the new code
 paths.

OK, patch applied.

 Are you sure that log_executor_stats is the only missing case?

You are asking if other things are in the Multi path but not in the
non-multi path.  The only thing I saw was this from PortalRunMulti:

/*
 * If a command completion tag was supplied, use it.  Otherwise use
 * the portal's commandTag as the default completion tag.
 *
 * Exception: clients will expect INSERT/UPDATE/DELETE tags to have
 * counts, so fake something up if necessary.  (This could happen if
 * the original query was replaced by a DO INSTEAD rule.)
 */
if (completionTag  completionTag[0] == '\0')
{
if (portal-commandTag)
strcpy(completionTag, portal-commandTag);
if (strcmp(completionTag, INSERT) == 0)
strcpy(completionTag, INSERT 0 0);
else if (strcmp(completionTag, UPDATE) == 0)
strcpy(completionTag, UPDATE 0);
else if (strcmp(completionTag, DELETE) == 0)
strcpy(completionTag, DELETE 0);
}

Oh, I see this too:

ereport(DEBUG3,
(errmsg_internal(ProcessQuery)));

I will duplicate that one in the right place.

 Also, I am not sure that the code paths for extended query messages
 are doing logging correctly.  I recall being worried about how to
 translate the logging definitions into situations where parsing and
 execution are separate, or where a statement may be partially executed
 and then we come back for more.  I didn't have time in the 7.4 cycle to
 really think about it, but someone should take a look.

How do we test that?

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]