COmanage Developers List

[Benn Oshrin <>]

Alrighty.

On 9/18/13 8:15 PM, Marie Huynh wrote:
> It sounds like we are in agreement.  Shall I commit it?
>
>
> On Wed, Sep 18, 2013 at 4:53 PM, Benn Oshrin 
> <
> <mailto:>>
>  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-