Thank you for many works. Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers