Re: contrib/pg_stat_statements 1226

From: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org, "Alex Hunsaker" <badalex(at)gmail(dot)com>
Subject: Re: contrib/pg_stat_statements 1226
Date: 2009-01-05 02:52:00
Message-ID: 20090105104408.31DC.52131E4D@oss.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thank you for many works.

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> 1. The proposed change to track system/user CPU time presents an
> enormous cost, and no argument has been made to show that there is any
> comparable benefit.

> 2. I'm unconvinced by the proposed changes to accumulate backend-local
> I/O counters, too. The fact of the matter is that those counters are
> left over from Berkeley days, a time when PG hackers tended to do their
> performance measurements in standalone backends (!).

Ok, I need to reconsider performance and design of I/O counters.
I think those information is still useful because we can determine
not only which query is bad, but also why the query is bad
*without repeating the query in production servers*.
But the reworking would be done in 8.5...

> * I changed the default track setting to "top". I don't see the
> likelihood that someone would load this module into their server
> and not want it turned on.

Looks good. Setting shared_preload_libraries is enough for normal use.

> * I'm not entirely seeing the point of a server-wide tracking facility
> that only counts SELECT/INSERT/UPDATE/DELETE. ISTM this should be
> modified to count utility commands too; which probably means adding some
> hooks around ProcessUtility (and what about autovacuum?). I left that
> work for someone else to do, though.

Sure, but we should also consider utility commands should not kick out
DML queries because maintenance commands take long time typically.

> * As already mentioned I find the entry_dealloc logic pretty darn
> dubious; but I didn't touch that either in this go-round. If we do
> keep it in its current form, ISTM that usage ought to be proportional
> to total execution time not total call count.

I think the current implementation is not ideal, too.
I also don't like using fixed-size shared memory. I'm thinking
that shared memory used by extended modules to be allocated
from the shared buffer pool in the future. If we could do it,
memory management will be flexible and we can load libraries
after server starts.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-01-05 02:56:42 SPI nesting in plperl
Previous Message KaiGai Kohei 2009-01-05 02:42:31 Re: generic reloptions improvement