Getting counts from detail tables

Question

I have multiple record bock that displaye a list of cell ids and their attributes; each record also displays record counts of its 3 detail tables.
Originally, the POST-QUERY trigger select the counts (3 detail tables) as part of the data block for each record (or cell id). There are over 16K records, so each record query issues 3 selects. The whole query toke over a minute. I was asked to improve the retrieval time.
At first I thought perhaps I could put the 3 counts in 3 separate data blocks and issue one query each in a "select cell_id, count(*). . . group by cell_id" but scrolling would not synchronize with the other blocks. So I dropped that idea.
Next, I added a program unit from which the WHEN-NEW-FORM-INSTANCE trigger calls after execute_query. It issues "select cell_id, count(*). . . group by cell_id" (one for each detail table) and fills the count columns in the original data block. However I need to set the block property Query All Records to YES so that the cell ids and attributes are filled first. That means that before the form comes up it has to retrieve all records. That saves me about 10-15 seconds od retrieval time and I lose the ability to quickly bring up the form.
Then I looked at using dfferent Query Data Source Types. I don't think I could do one query with counts of detail tables. Besides, some items (attrinutes) of the cell are upate-able.
Any ideas and suggestions will be appreciated.

Answer 1

Yes. I suggested adding columns to the master tables and introduce stored triggers.
Since the change is not trivial, according to management, they put in on hold.I'm not sure if you misunderstood my suggestion or were responding to a different post. The query I wrote was for counting the detail records on the fly rather than populating new columns. If you include the counting in your main query then you will probably not have a much slower query than if you don't show any counts at all. Scrolling through the block will be no slower than if you had no counts, because no extra processing needs to be done. (You'll still have to fetch the detail blocks for each row, so moving to the last record will still be slow - that's a bad indicator of the performance of a query.)
For example, fetching the objects for each user takes 5 seconds. When I include the number of tables, indexes and constraints for each user within the query the time only goes up to just under 9.
SQL> set autot trace stat
SQL> set timing on
SQL> SELECT
  2    owner,
  3    object_name,
  4    object_type
  5  FROM all_objects ao;
39062 rows selected.
Elapsed: 00:00:05.13
Statistics
       4656  recursive calls
          0  db block gets
      85106  consistent gets
          0  physical reads
          0  redo size
    1469372  bytes sent via SQL*Net to client
      29021  bytes received via SQL*Net from client
       2606  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
      39062  rows processed
SQL> SELECT
  2    owner,
  3    object_name,
  4    object_type,
  5    (SELECT Count(*) FROM all_tables WHERE owner = ao.owner) count_tables,
  6    (SELECT Count(*) FROM all_indexes WHERE owner = ao.owner) count_indexes,
  7    (SELECT Count(*) FROM all_constraints WHERE owner = ao.owner) count_constraints
  8  FROM all_objects ao;
39062 rows selected.
Elapsed: 00:00:08.86
Statistics
       4656  recursive calls
          0  db block gets
     270299  consistent gets
          0  physical reads
          0  redo size
    1684042  bytes sent via SQL*Net to client
      29021  bytes received via SQL*Net from client
       2606  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
      39062  rows processed
SQL> If you populate the counts in post-query then the process is similar to the block below. I tried to get a timing and stats for this but it took over 15 minutes so I shut it down.
DECLARE
ct NUMBER;
ci NUMBER;
cc NUMBER;
BEGIN
  FOR ao IN (SELECT owner, object_name, object_type FROM all_objects)
  LOOP
    SELECT Count(*) INTO ct FROM all_tables WHERE owner = ao.owner;
    SELECT Count(*) INTO ci FROM all_indexes WHERE owner = ao.owner;
    SELECT Count(*) INTO cc FROM all_constraints WHERE owner = ao.owner;
  END LOOP;
END;Creating a view on the query and writing the "instead of" triggers is hopefully a trivial enough operation that management won't get in the way. Then you'll be able to update the block.