Skip to Content.
Sympa Menu

comanage-dev - [comanage-dev] Re: CO693 - Navigation Links Table Definitions

Subject: COmanage Developers List

List archive

[comanage-dev] Re: CO693 - Navigation Links Table Definitions


Chronological Thread 
  • From: Marie Huynh <>
  • To: Benn Oshrin <>
  • Cc: comanage-dev <>
  • Subject: [comanage-dev] Re: CO693 - Navigation Links Table Definitions
  • Date: Wed, 18 Sep 2013 17:15:06 -0700

It sounds like we are in agreement.  Shall I commit it?


On Wed, Sep 18, 2013 at 4:53 PM, Benn Oshrin <> wrote:
On 9/18/13 7:46 PM, Marie Huynh wrote:
Is this what you mean?

+    <field name="created" type="T" />
+    <field name="modified" type="T" />
-    <!-- XXX almost certainly need to create some indexes here -->
+    <index name="co_navigation_links_i1">
+      <col>co_id</col>
+    </index>

More or less.


Every row of navigation_links is used for every page load so I expect
the system to cache it in production and not need an index.  Does it
not?  I also expect the co-level ones to be cached since they shouldn't
change very often.

Let's say an instance has 1000 CoNavigationLinks defined across 100 COs. You're only pulling CoNavigationLinks for a given CO, say co_id=7. This translates to a query like

 SELECT * FROM cm_co_navigation_links WHERE co_id=7;

If there is no index on co_id, then the database needs to look at all 1000 records to find the 10 that you're interested in. This doesn't scale. By adding the index, the search time is always O(1) instead of O(n). Even if cake is caching, whenever the cache expires (or the results aren't cached yet), the database has to perform O(n) operations without the index, resulting in arbitrary (and hard to diagnose) slow page loads.

NavigationLinks is different, since as you point out we always need to retrieve all of them (and there aren't going to be that many in the first place).

-Benn-




Archive powered by MHonArc 2.6.16.

Top of Page