Thank you very much! Your query is exactly what I was looking for. If I understand you correctly, the main bottleneck is the count in the inner select - is that correct? (disregarding the overall loop for all groups)
Am 05.10.2010 um 12:24 schrieb Drake Wilson: > Quoth Mail <sv...@gmx.net>, on 2010-10-05 11:43:29 +0200: >> SELECT COUNT(DISTINCT t0.Z_PK) FROM ZFFFOOD t0 WHERE (t0.ZFOODGROUP >> = ? AND (SELECT COUNT(*) FROM ZFFWEIGHT t1 WHERE (t0.Z_PK = >> t1.ZFOOD) ) > ?) > > There should not need to be a DISTINCT when talking about a primary > key. They will already be distinct by definition, no? (I'm assuming > your primary keys will not be null, even though you don't have a NOT > NULL constraint on the column.) > > Aside from that, if you want "at least one", EXISTS is the obvious > operator to use rather than first requesting the count (and having to > iterate all the rows even though only the first one is needed to > demonstrate existence.) > >> My current task is to get the number of foods that belong to each >> group and have at least one weight data related to them. > > That suggests something like: > > SELECT g.Z_PK AS "group", COUNT(f.Z_PK) AS "count" > FROM ZFFFOODGROUP g > INNER JOIN ZFFFOOD f ON f.ZFOODGROUP = g.Z_PK > WHERE EXISTS (SELECT w.Z_PK FROM ZFFWEIGHT w WHERE w.ZFOOD = f.Z_PK) > GROUP BY g.Z_PK; > > (I think the WHERE EXISTS could be done with another join, but it > would probably be more convoluted.) > >> When inserting 12 for ZFOODGROUP and 0 for count (I never check for >> another count value here, it's always 0), I get a result of 761 >> which takes 0.0591 seconds. As I have to fetch the counts of all >> available groups, this query is sent in a loop which easily takes >> several seconds to finish. > > Do the loop in the query itself using GROUP BY instead, if you can, > rather than issuing several queries. > > My local, unrigorous measurements suggest that on my machine, with the > provided example database, your original query takes 40 ms of CPU per > run and the above takes 16 ms total; I imagine the use of GROUP BY and > EXISTS and the lack of the extra DISTINCT are the primary factors, but > I haven't checked thoroughly enough to say so confidently. I'm using > SQLite 3.7.2 on Debian GNU/Linux sid AMD64. > > ---> Drake Wilson > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users