> Do other SQL database engines not have this same limitation?" Are MySQL
> and PostgreSQL and Firebird and MS-SQL and Oracle creating phantom
> indices on-the-fly to help them do joins faster, for example?" Or do
> their optimizers do a better job of finding ways to use indices in a
> join?"
As others have already mentioned, hash joins can help in a
situation where there are no appropriate indexes. They can make
things worse if the inputs aren't large enough though, so there's
still some gray area.
The biggest thing that other databases have going for them - MSSQL
and Oracle at
* D. Richard Hipp:
> One of the criticisms of SQLite is that it is slow to do joins. That
> is true if SQLite is unable to figure out how to use an index to speed
> the join. I was under the impression that SQLite actually did a
> fairly reasonable job of making use of indices, if they exi
On Sat, May 30, 2009 at 07:01:31PM +0100, Simon Slavin wrote:
> I'm interested in how sqlite works differently to the SQL systems
> which keep a daemon running as a background task. One of the
> advantages of having a daemon which persists between runs of an
> application is that the daemon
SQLite has surprised me with its quick performance, not the other way
around. In fact, I've implemented all kinds of lookup queries that I
knew could be optimized by caching results so I didn't have to keep
repeating the SQL query, but the performance was so good even
repeating the queries that I
I'm interested in how sqlite works differently to the SQL systems
which keep a daemon running as a background task. One of the
advantages of having a daemon which persists between runs of an
application is that the daemon can keep its own list of ORDERs, and
JOINs which are asked for frequ
D. Richard Hipp wrote:
> There has been a recent flurry of comments about SQLite at
>
> http://www.reddit.com/r/programming/comments/8oed5/how_sqlite_is_tested/
> http://news.ycombinator.com/item?id=633151
>
> One of the criticisms of SQLite is that it is slow to do joins. That
> is tr
Assuming memory is sufficiently inexpensive, I would think that it
would almost always be useful to build an index for any field in a
join rather than doing a full scan. (Or better yet, build a hash table
if memory is sufficient.) Indices maintained in the database then
become optimizations
> Do other SQL database engines not have this same limitation? Are
> MySQL and PostgreSQL and Firebird and MS-SQL and Oracle creating
> phantom indices on-the-fly to help them do joins faster, for example?
Sort of. There's 2 types of join methods in Oracle for this - Hash
joins and Sort merge joi
There has been a recent flurry of comments about SQLite at
http://www.reddit.com/r/programming/comments/8oed5/how_sqlite_is_tested/
http://news.ycombinator.com/item?id=633151
One of the criticisms of SQLite is that it is slow to do joins. That
is true if SQLite is unable to figure ou
10 matches
Mail list logo
