Granted, I glazed over that fact. What I did see, though, is the blank=True on a CharField(), which would indicate to me that multiple '' (empty string) entries could potentially be inserted into the database, meaning that it can't be unique (with implied null=False).
*confused* I'm guessing the model definition doesn't quite match the database, and given the amount of data, wasn't created using Django (hinted at by managed=False), although I have no experience with Oracle DB's. The operation needs to be profiled to determine where the bottleneck is. Obviously pulling a single record and coercing it into a small model shouldn't take that long. The OP also posted a second SQL query with two sub-SELECTS in it, which is probably less efficient, and I have no idea where it came from. Also, a return on a search against 1.5b rows, even with an index, would probably not take < 0.1sec (100ms if that number is accurate). It's possible/likely that the DB was caching the (now repeated) query, and skewing the timing results. It'd be interesting to determine whether or not the DB is caching the query, and then re-run the operation with the same Django model call several times to see if the timing drops down into the sub-second range (it should). -James On Fri, Jan 23, 2015 at 12:05 AM, Erik Cederstrand < erik+li...@cederstrand.dk> wrote: > > > Den 23/01/2015 kl. 08.19 skrev James Schneider <jrschneide...@gmail.com > >: > > > > How many results do you typically get back from that query? > > There should be only one result, right? Since the "markid" field is > defined as unique and OP is filtering on that with a single value. > > First thing to check is that the actual column in Oracle is also unique, > and that there is an index on that column alone. AFAIK Django creates an > index automatically on unique fields. > > The cx_oracle client may be cheating by returning when the query > completed, but before results are actually fetched. > > Erik > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-users+unsubscr...@googlegroups.com. > To post to this group, send email to django-users@googlegroups.com. > Visit this group at http://groups.google.com/group/django-users. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-users/0898444F-6539-4191-B766-BFE248586F37%40cederstrand.dk > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CA%2Be%2BciWLhUbdkuDg%2BwerRpWCheYNVgi-7bxe2UrDg2_Y87At5A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
