From: | "Alex Hunsaker" <badalex(at)gmail(dot)com> |
---|---|
To: | "ITAGAKI Takahiro" <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: contrib/pg_stat_statements 1202 |
Date: | 2008-12-09 19:32:35 |
Message-ID: | 34d269d40812091132n669f0d91jb85f87e86f14f359@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Dec 7, 2008 at 19:13, Alex Hunsaker <badalex(at)gmail(dot)com> wrote:
> On Tue, Dec 2, 2008 at 02:35, ITAGAKI Takahiro
> <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> wrote:
>> Here is an update version of contrib/pg_stat_statements.
>
> Hello again!
>
> I was assigned to review this.
... Some other things I accidentally left out.
#define GUCNAME(name) ("statistics." name)
Why statistics?
Would not something like stat_statements make more sense? Statistics
seems fairly arbitrary...
Also per the
/* XXX: Should USAGE_EXEC reflect execution time and/or buffer usage? */
Maybe it should be configurable, personally I would want something
like # of calls / time. Mainly because I don't for instance really
care that my backups get tracked but would be more interested in the
things that get called most often that also take the longest. (aka
the most bang for the buck, as far as optimizing those goes...)
?
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2008-12-09 19:36:31 | Re: parallel restore vs. windows |
Previous Message | Pavel Stehule | 2008-12-09 19:31:05 | Re: WIP: default values for function parameters |