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?

Mike Mascari
mascarm@mascari.com

-----Original Message-----
From:	Denis Perchine [SMTP:dyp@perchine.com]

That's bad. Cause it will be unuseful for people having databases far 
away...
Like me... :-((( Another point is that it is a little bit strange to have
X-Window on machine with database server... At least if it is not for play, 
but production one...

Also there should be a possibility of remote monitoring of the database. 
But
that's just dream... :-)))

--
Sincerely Yours,
Denis Perchine


Tue, 13 Mar 2001 05:58:12 -0500
Mike Mascari <mascarm@mascari.com>
RE: Performance monitor
> 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, Pennsylvania 19026

Tue, 13 Mar 2001 10:00:35 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Performance monitor