For what its worth,

Oracle has a nice feature for resource management called PROFILEs:

CREATE PROFILE profile LIMIT
[ SESSION_PER_USER [ session_limit | UNLIMITED | DEFAULT ] ]
[ CPU_PER_SESSION cpu_session_limit | UNLIMITED | DEFAULT ] ]
[ CPU_PER_CALL cpu_call_limit | UNLIMITED | DEFAULT ] ]
[ CONNECT_TIME connect_limit | UNLIMITED | DEFAULT ] ]
[ IDLE_TIME idle_limit | UNLIMITED | DEFAULT ] ]		
[ LOGICAL READS_PER_SESSION read_session_limit | UNLIMITED | DEFAULT 
] ]		
[ LOGICAL READS_PER_CALL read_call_limit | UNLIMITED | DEFAULT ] ]		
[ PRIVATE_SGA memory_limit | UNLIMITED | DEFAULT ] ]		
[ COMPOSITE_LIMIT resource_cost_limit | UNLIMITED | DEFAULT ] ]

which limits things like CPU_PER_CALL and LOGICAL_READS_PER_SESSION 
to a profile. The ALTER USER command then allows you to assign a 
PROFILE to a user. This is really nice, since you can prevent 
run-away queries from denying service by the database to other users. 
It also can prevent a user from soaking up all of the available 
connections. You must set a flag in your initSID.ora configuration 
profile for ORACLE to support profiles. Since Jan is collecting these 
statistics any way (if the appropriate configuration flag is set), it 
would be pretty trivial to implement PROFILEs in PostgreSQL.

Mike Mascari
mascarm@mascari.com

-----Original Message-----
From:	Tom Lane [SMTP:tgl@sss.pgh.pa.us]

Jan Wieck <JanWieck@Yahoo.com> writes:
>     So outing myself not beeing a *real programmer*, this is what
>     I have so far:

Hmm ... what is the performance of all this like?  Seems like a lot
of overhead.  Can it be turned off?

>     * Backends call some collector functions  at  various  places
>       now  (these  will  finally  be macros), that count up table
>       scans, tuples returned by scans,  buffer  fetches/hits  and
>       the like.

Have you removed the existing stats-gathering support
(backend/access/heap/stats.c and so on)?   That would buy back
at least a few of the cycles involved ...

			regards, tom lane


Fri, 1 Jun 2001 10:45:03 -0400
Mike Mascari <mascarm@mascari.com>
RE: Access statistics 