Re: [sqlite] Feature request: merge joins (preferably through a hint)

2017-11-07 Thread Simon Slavin
On 7 Nov 2017, at 7:59am, Davor Josipovic wrote: > What sqlite does now is for each "a" it searches through the index for "x". If an ideal index already exists, accessing the correct records will be fast. If one does not exist, how would you expect a merge join to be any

Re: [sqlite] Feature request: merge joins (preferably through a hint)

2017-11-07 Thread Davor Josipovic
> You are thinking that perhaps queries such as the following might > be faster using a merge: > > SELECT * FROM tab1 JOIN tab2 ON tab1.a=tab2.x; > > I disagree. I don't see any reason to disagree. Merge join will definitely be faster if the data is already sorted. See the reference:

Re: [sqlite] Feature request: merge joins (preferably through a hint)

2017-11-05 Thread Simon Slavin
On 5 Nov 2017, at 11:04am, Richard Hipp wrote: > SQLite does do a merge in some cases, though not for what you would > traditionally call a join. For example, SQLite will do a merge to > combine the two halves of this query: > >SELECT a,b,c FROM tab1 UNION SELECT x,y,z

Re: [sqlite] Feature request: merge joins (preferably through a hint)

2017-11-05 Thread Richard Hipp
On 11/5/17, Davor Josipovic wrote: > Merge joins could be an incredible optimization in some cases for large > queries and would make sqlite much faster in such cases. SQLite does do a merge in some cases, though not for what you would traditionally call a join. For example,