> I don't want to look a gift horse in the mouth, but it seems to me that the
> performance monitor should wait until the now-famous query tree redesign
> which will allow for sets from functions. I realize that the shared memory
> requirements might be a bit large, but somehow Oracle accomplishes this
> nicely, with some > 50 views (V$ACCESS through V$WAITSTAT) which can be
> queried, usually via SQL*DBA, for performance statistics. More then 50
> performance views may be over-kill, but having the ability to fetch the
> performance statistics with normal queries sure is nice. Perhaps a
> postmaster option which would enable/disable the use of accumulating
> performance statistics in shared memory might ease the hesitation against
> it?
I don't think query design is an issue here. We can already create
views to do such things. Right now, pgmonitor simply uses 'ps'. and
uses gdb to attach to the running process and show the query being
executed. For 7.2, I hope to improve it. I like the shared memory
ideas, and the ability to use a query rather than accessing shared
memory directly.
Seems we should have each backend store query/stat information in shared
memory, and create special views to access that information. We can
restrict such views to the postgres super-user.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026