Opened 12 years ago

Closed 11 years ago

#142 closed enhancement (fixed)

Make sure we're using 100% efficient queries / indexes

Reported by: Christopher Allan Webber Owned by: Christopher Allan Webber
Priority: trivial Milestone:
Component: programming Keywords: post-sql
Cc: Parent Tickets:

Description (last modified by Christopher Allan Webber)

Every query we use should be able to efficiently use an index, yet
at the same time, we shouldn't create superflous indexes.


-  ` <>`_
-  ` <>`_
-  ` <>`_

Especially, we should play with using explain:

`{{explain <>`_}}.

Assigning to myself, but feel free to claim this if you're excited
about investigating.

Change History (11)

comment:1 by Caleb Davis, 12 years ago

This bug inspired the following update to `#360 </issues/360>`_:

` <>`_

Here's what I propose:

-  place at least one example of a proper search query in a comment
   alongside a new index
-  assert within a unit test that the example query uses the target
-  do the analogous thing for new queries. name the target index in
   a comment alongside the query, and provide a unit test

These requirements should be met before merging a new index/query.
The merger can then focus on evaluating the cost/benefit. I'll add
unit tests and comments on `#360 </issues/360>`_, at least.

It's rather rigid, I suppose, but I think we need *some* system.
Otherwise this bug could arguably be opened every time someone
makes a new query or index. Under the proposed system, we can be
confident the queries are locked down by unit tests. When we need a
new query we could scan the indices to see if there is a suitable
one already available. Likewise, we would have a way to update all
the appropriate queries if we have to get rid of or change an

comment:2 by Christopher Allan Webber, 12 years ago

I approve of that idea.

comment:3 by Will Kahn-Greene, 12 years ago

We release 0.0.4, so I'm bumping this to 0.0.5.

comment:4 by Christopher Allan Webber, 12 years ago


comment:5 by Christopher Allan Webber, 12 years ago


comment:4 by Elrond, 12 years ago

Priority: NormalLow
I doubt this gets adressed for 0.2.0.

And as we're concentrating on SQL now, I've set this to Low
It might get revisited in the SQL world again, with a lot of
different meaning then. But until that time, it's surely Low

comment:5 by Will Kahn-Greene, 11 years ago

The original url for this bug was .
#241: related, #55: related, #31: blocked, #379: blocked

comment:6 by Elrond, 11 years ago

Keywords: post-sql added

comment:7 by Christopher Allan Webber, 11 years ago

This is technically mostly relevant, just in the SQL world now. Elrond and I said we'd discuss soonish.

comment:8 by Elrond, 11 years ago

Milestone: 0.2.1
Type: defectenhancement

We will try to add some indexes to the sql models as we go, but this really is currently low priority and we're not aiming to adress this for the next release (because the next release aims at "get sql running").

comment:9 by Christopher Allan Webber, 11 years ago

Description: modified (diff)
Resolution: fixed
Status: acceptedclosed

I think we put some time into making efficient indexes, and I'm pretty sure that we'll update indexes from real actual experience as we go from here on out. I'm closing this ticket!

Note: See TracTickets for help on using tickets.