Re: contrib/pg_stat_statements 1202

Поиск
Список
Период
Сортировка
От Alex Hunsaker
Тема Re: contrib/pg_stat_statements 1202
Дата
Msg-id 34d269d40812091132n669f0d91jb85f87e86f14f359@mail.gmail.com
обсуждение исходный текст
Ответ на Re: contrib/pg_stat_statements 1202  ("Alex Hunsaker" <badalex@gmail.com>)
Ответы Re: contrib/pg_stat_statements 1202  (ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>)
Список pgsql-hackers
On Sun, Dec 7, 2008 at 19:13, Alex Hunsaker <badalex@gmail.com> wrote:
> On Tue, Dec 2, 2008 at 02:35, ITAGAKI Takahiro
> <itagaki.takahiro@oss.ntt.co.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...)

?


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Pavel Stehule"
Дата:
Сообщение: Re: WIP: default values for function parameters
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: parallel restore vs. windows