Re: SQL query plan question
- From: schulz@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx (Stephan Schulz)
- Date: Tue, 22 Aug 2006 13:34:38 +0000 (UTC)
In article <44b7ce87$0$6033$9a6e19ea@xxxxxxxxxxxxxxxxxxxx>, Chris wrote:
Suppose we have a very large table in a SQL database, and want to
execute this query:
select *
from table
where price > 10.00
order by name
Assume that both price and name are high-cardinality columns, that is,
there is a very large number of unique values in each column.
Suppose that we have an index on price, and an index on name, but we do
*not* have an index on price + name.
Is there any query plan that can evaluate this query efficiently? I'm
not seeing one, but I really hope that there is. From what I see, if we
start by traversing the name index, we'll have to do a full table scan.
If we traverse the price index, then we'll have to accumulate all the
names and do a brute-force sort.
Well, sorting with a decent algorithm is only O(n log n), thus not too
bad even for fairly large n.
Here's one other little twist: we do not have to return the entire
result set, only the first 10 records.
I don't know about SQL, but in general, finding the k largest (for a
constant k) elements from a list of n elements can be done in O(n)
without sorting.
Bye,
Stephan
--
-------------------------- It can be done! ---------------------------------
Please email me as schulz@xxxxxxxxxxx (Stephan Schulz)
----------------------------------------------------------------------------
.
- Prev by Date: Turing completeness, and generation of non-Turing complete code to solve problems that would typically require Turing complete languages
- Next by Date: Re: Diopantine Equations and comp science
- Previous by thread: Turing completeness, and generation of non-Turing complete code to solve problems that would typically require Turing complete languages
- Next by thread: Noob question on complexity of emulated machines?
- Index(es):
Relevant Pages
|