NG INTEGER PRIMARY KEY (rowid=?)}
It would be easy enough again for the planner to deduce this, but as Ryan
Smith described, may not be worth doing in the general case. I don't know.
I'm just reporting
GER PRIMARY KEY (rowid=?)}
2 0 0 {SEARCH TABLE a USING COVERING INDEX idx_ref (ref=? AND rowid=?)}
7 0 0 {USING ROWID SEARCH ON TABLE b FOR IN-OPERATOR}
--
Poor Yorick
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
On Wed, Apr 17, 2019 at 11:36:18AM +0200, R Smith wrote:
> On 2019/04/17 10:55 AM, Poor Yorick wrote:
[SNIP]
>
> In your above example you really wish to know all the a's which have an
> entry in b. The first query asks to join and list all b's found for every a
> (which works
ot; case as well?
--
Poor Yorick
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
easy optimisation
opportunity here?
select a.rowid
from a join b on a.rowid = b.rowid
where a.ref = $x
select a.rowid
from a,b
where a.ref = $x and a.rowid in (select rowid from b)
--
Poor Yorick
___
sqlite-users mailing list
sqlite-users
into t values ("h") , ("he")
}
set record 2
db eval {select * from t} record {
puts [list row [array get record]]
}
Of course, one reasonable answer is, "Then don't do that!", but it would
be
less surprising if the underlying error propagated
On 2016-02-08 19:15, Richard Hipp wrote:
> On 2/8/16, Richard Hipp wrote:
>> On 2/8/16, Poor Yorick wrote:
>>> The following query produces a third phantom record on my system:
>>
>> Running "PRAGMA automatic_index=OFF;" might alleviate the symptoms
&g
eav.attribute == :report3
order by eav.id
}]
= end script =
The result is:
3 1 name Imogen 5 1 gender female 5 1 1 female
--
Poor Yorick
8 matches
Mail list logo
