Although Oracle doesn't have LIMIT, it does have ROWNUM which basically acts as a counter. So I think you should do:
SELECT 1 FROM [table] WHERE [where] AND ROWNUM <= 1; When there are JOINS you probably have to put the original SELECT in a subquery of the ROWNUM <= 1 query. More info about ROWNUM: http://www.oracle.com/technology/oramag/oracle/06-sep/o56asktom.html I believe some databases are actually quite slow when doing a COUNT(*). (Can't remember which RDBMS I experienced this). Regards, - Matthias On Jul 14, 5:31 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Fri, 2007-07-13 at 16:22 -0500, Adrian Holovaty wrote: > > I'd like to add a QuerySet.exists() method, which would return True or > > False if the given QuerySet contains at least one record. This would > > be more efficient than qs.count() or len(qs) because it would perform > > the following SQL under the hood: > > > SELECT 1 FROM [table] WHERE [where] LIMIT 1; > > Due to Oracle inclusion, this has to be > > select count(*) from [table] where [...] > > and then check that the result is > 0, at least in the Oracle backend > (no "limit" extension in Oracle). The problem being that count(*) is not > an optimised operation in PostgreSQL, however, we haven't yet split up > those cases in a lot of the code (the recent Oracle merge moved a bunch > of similar things to the count(*) case and I keep meaning to look at > whether we can move them all to count(id_col), which is faster). > > > I'm biased, because I have an immediate need for this in a project, > > but this seems general and useful enough for inclusion in QuerySet. > > Thoughts? > > I'm +0. > > __nonzero__ needs a bit more care, though, I think (although we need it > and it's my fault it hasn't been implemented so far; I'm dragging my > feet a bit too much in this area). We can implement __nonzero__ (more > importantly, make bool() make sense) using a single item lookahead cache > internally. So when you call __nonzero__, it pulls back the first item > to check if it exsits and the subsequently iterating over the queryset > will still return that first item before the rest. Net result is that it > doesn't require two SQL queries to do this: > > if qs: > # do something with the results of qs > > which is pretty easy to walk into in templates. > > By the way, for all database backends except SQLite, you can implement > all of this sort of stuff (including exists and __len__) fairly fast > using cursor.rowcount (the number of rows in the result set). > Unfortunately, SQLite always returns -1 for rowcount. I'm building a few > of those optimisations into the QuerySet rewrite as a way to cut down on > queries. > > Regards, > Malcolm > > -- > Experience is something you don't get until just after you need > it.http://www.pointy-stick.com/blog/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
