Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming.threads > #1308
| 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.
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
Re: HashDbase and parallel hashlist... Robert Wessel <robertwessel2@yahoo.com> - 2013-01-18 15:18 -0600
csiph-web