[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference orarep::nomahs::rdb_wish

Title:Oracle Rdb Wishes and Suggestions
Notice:Please READ note 1.0 before using WRITE or REPLY
Moderator:NOVA::SMITHI
Created:Fri Apr 07 1989
Last Modified:Mon Jun 02 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:809
Total number of notes:4111

800.0. "workload statistics collection per user, image ..." by 12293::ALLEMEERSCH (In Flanders fields ...) Tue Apr 01 1997 13:21

    
    There seems to be a lot of anxiety and concern on the possible
    overhead, locking, concurrency etc ... during workload statistics
    collection. 
    
    Some more information is welcomed here !
    Who is writing to rdb$workload, how is concurrency handled ... ?
    
    Hence the wish to enable/disable workload statistics collection
    per user, image, pid ..., similar as Trace allows to do, using
    a registration id. This would be a elegant way to exclude ad hoc
    infrequent queries.
    
    _Luc
T.RTitleUserPersonal
Name		DateLines
800.1NOVA::SMITHIDon't understate or underestimate Rdb!Wed Apr 02 1997 02:317
~    Who is writing to rdb$workload, how is concurrency handled ... ?

The optimizer collects the statistics during processing the query.  We flush
the ICG information to RDB$WORKLOAD during commit processing, in the same way
we flush cardinality updates.

Ian
800.2bottom line ?12293::ALLEMEERSCHIn Flanders fields ...Wed Apr 02 1997 06:395
    So to reassure the customers, we could have a position along the
    lines: 'If you can live with cardinality updates, workload collection
    should not have more observable overhead' . Right ?
    
    _Luc
800.3NOVA::SMITHIDon't understate or underestimate Rdb!Wed Apr 02 1997 14:515
I didn't say that, but we designed the system to have as low an impact as
possible.  However, there is an impact and the user must decide if they want
to incur the read/write overhead for collecting this data.

Ian