Forum OpenACS Development: Re: calendar in .LRN really slow

Collapse
Posted by Bernt Pettersen on
Without time_intervals and timespans the query uses almost no time... (dont know exactly)

I'll check for indexes in a while...

Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=54 Card=147 Bytes=16
          317)

   1    0   HASH JOIN (Cost=54 Card=147 Bytes=16317)
   2    1     HASH JOIN (Cost=43 Card=150 Bytes=14850)
   3    2       HASH JOIN (Cost=32 Card=150 Bytes=4650)
   4    3         TABLE ACCESS (FULL) OF 'CAL_ITEMS' (Cost=10 Card=150
           Bytes=1800)

   5    3         TABLE ACCESS (FULL) OF 'ACS_EVENTS' (Cost=21 Card=11
          940 Bytes=226860)

   6    2       TABLE ACCESS (FULL) OF 'ACS_ACTIVITIES' (Cost=10 Card=
          3050 Bytes=207400)

   7    1     TABLE ACCESS (FULL) OF 'CAL_ITEMS' (Cost=10 Card=11670 B
          ytes=140040)





Statistics
----------------------------------------------------------
          4  recursive calls
         25  db block gets
        334  consistent gets
          0  physical reads
          0  redo size
        844  bytes sent via SQL*Net to client
        430  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

Collapse
Posted by Dirk Gomez on

It now uses full-table scans for all tables - which it shouldn't. At least the table that contains the field start_date should be accessed via an index because you want only a *very few* rows from that table. Looks quite weird.

Anyway the join between time_intervals and timespans is gigantic (30.000x15.000). Does someone know what they mean with respect to calendar?