On Thu, 16 Jun 2016 23:23:33 +0200 Dominique Devienne <ddevie...@gmail.com> wrote:
> > > On Behalf Of James K. Lowden > > > > > > create view vParts as > > > select 1 as Matched, * from Parts > > > UNION > > > select 0, * from UnmatchedParts > > > > Why UNION instead of UNION ALL here? > Thanks to the 1 and 0, there can't be any dups, so the dedup step of > UNION wastes cycles, no? Well spotted, yes! (Maybe one of these days we'll have a relational query language without the strange "select distinct / union all" contradiction.) I think you're right that, by construction, these two sets are distinct. I was going to suggest that perhaps SQLite could detect that case, and skip the de-duplication step. But I think it's a bridge too far. To begin with, there's no way in SQL to *declare* two tables represent distinct sets. If we can't even do that, how can the DBMS be expected to deduce that any two derived sets are distinct? --jkl _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
