Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.programming.threads > #1308

Re: HashDbase and parallel hashlist...

From Robert Wessel <robertwessel2@yahoo.com>
Newsgroups comp.programming.threads, comp.programming
Subject Re: HashDbase and parallel hashlist...
Message-ID <2gejf81pogjo94kgdlf5hm0uaf8mahrgr6@4ax.com> (permalink)
References <kd6n55$fb1$1@dont-email.me> <kd9o39$2b9$1@dont-email.me>
Organization Forte Inc. http://www.forteinc.com/apn/
Date 2013-01-18 15:18 -0600

Cross-posted to 2 groups.

Show all headers | View raw


On Thu, 17 Jan 2013 15:48:33 -0800, aminer <aminer@toto.ca> wrote:

>
>Hello,
>
>
>What i don't like in databases such as MySQL etc.
>
>Suppose we have the following SQL statement
>
>"Select * from Computers where hardisk < 250 and harddisk > 1000
>     or processors < 12   and processors > 4"
>
>So as you have noticed even  if the database is indexed on the field 
>"hardisk" the  first part "where hardisk < 250 and harddisk > 1000" will 
>be fast but the second part "processors < 12   and processors > 4" will 
>be done with a sequential search so it will  be slow , so imagine that 
>you have an SQL  querie like that
>that involve many rows and many fields and the databAse
>is working on hardisk records, the databases such as MySQL etc. will get 
>very slow and that's why i don't like databases, you will
>get the same problem with SQL joins they can get very slow also.
>
>Am i missing something here ?


Please stop top-posting.

Again, the optimum strategy depends on the data, but one common
technique is to read both indexes in the specified ranges, sort the
results based on the record ID, and then do a match merge on the two
lists.  Assuming a relatively small subset of records match each
range, that can be substantially more efficient.  If one range is very
selective (IOW matching only a few tuples), reading sequentially on
that index is no big deal, the critical factor being how expensive it
is to do that sequential scan (on some databases reading the table
sequentially in order of the primary key can be much faster than
reading by an alternate key).  If you're likely to return a large
portion of the table, a table scan might well be the best option.

Back to comp.programming.threads | Previous | Next | Find similar


Thread

Re: HashDbase and parallel hashlist... Robert Wessel <robertwessel2@yahoo.com> - 2013-01-18 15:18 -0600

csiph-web