Re: auto_explain contrib moudle

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: auto_explain contrib moudle
Date: 2008-11-17 17:00:34
Message-ID: 4260.1226941234@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> This would likely require adding a struct Instrumentation * field to
>> QueryDesc in which to track the total ExecutorRun timing

> I think instr_time is enough here,
> but why do you think Instrumentation is needed?

Well, it's more general. You could think of ExecutorRun as being like a
plan node, in which case all the fields of struct Instrumentation are
potentially useful. If a contrib module doesn't want to use them,
of course it doesn't have to.

Or I guess we could just put a void * there and not try to wire down
its usage.

> There might be another approach to have a stopwatch stack in
> the contrib module instead of the core. I think it is cleaner
> because it works even if multiple modules use the stopwatch
> at the same time. Am I missing something?

I think this will be mighty messy ...

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-11-17 17:09:44 Re: patch to fix client only builds
Previous Message Heikki Linnakangas 2008-11-17 16:56:02 Re: Synchronous replication patch v2