Hi Jacob, thx for reply and sorry for not enough additional info in
original post. I was thinking that this issue can be related only to
python part of the bench, as everything looked ok with queries. Just
in case I've tested query generated by only\defer queryset using raw
SQL bench and compared it to query with every field:
1.
for pk in xrange(1,50000):
cursor.execute ("SELECT `tests_user`.`id`,
`tests_user`.`name`, `tests_user`.`email`, `tests_user`.`age`,
`tests_user`.`power_level`, `tests_user`.`info` FROM `tests_user`
WHERE `tests_user`.`id` = %(pk)s", {'pk' : pk})
row = cursor.fetchone()
d = row[4]
2.
for pk in xrange(1,50000):
cursor.execute ("SELECT
`tests_user`.`id`,`tests_user`.`power_level` FROM `tests_user` WHERE
`tests_user`.`id` = %(pk)s", {'pk' : pk})
row = cursor.fetchone()
d = row[1]
1. ~27 sec
2. ~21 sec
This is expected result(asking for less fields = better performance)
I am using mysql database on the same PC with MyISAM engine
"test_user" table has 921,000 entries, all info fields have randomly
generated 400 chars of random ascii
On Aug 6, 1:09 am, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
> On Thu, Aug 5, 2010 at 3:44 PM, OverKrik <overk...@gmail.com> wrote:
> > Hi, I am testing performance of three querysets
>
> Good! We need as many benchmarks as we can get our hands on.
>
> > I was expecting first two querysets to be faster, but for some reason
> > it takes about ~105sec to finish (3) and ~130sec for (1) and (2)
> > I've checked queries generated by both querysets and can see that I am
> > not doing any extra requests to DB, and that (1) and (2) generates
> > correct SQL which includes only pk and power_level fields. I have
> > DEBUG=False when running tests.
> > Can this be a bug?
>
> Perhaps, but there's not enough information yet to know for sure.
> Anytime you're doing database performance testing, the particulars of
> the database and data set matter a *huge* deal. Before I could draw
> any conclusions from your data I'd want to know:
>
> - What database engine are you using?
> - Where's the database being stored (same server? other server? in-memory?)
> - How much data is in the database?
> - How big is that "info" field on an average model?
>
> If you're benchmarking this against a small dataset and an in-memory
> database like SQLite I'd fully expect to see the defer/only benchmark
> to be slower. That's because every time a QS is chained it needs to be
> copied, which is a relatively expensive operation. In a setup with
> small data, the time spent in Python is going to outweigh the time
> spent running the query in the database and sending the data over the
> wire.
>
> On the other hand, if I you have a million User objects with an
> average of 1K in the info field and you're running against a remote
> database -- situations that defer/only were specifically designed to
> optimize -- I'd be *very* worried if defer/only was slower.
>
> Make sense?
>
> Jacob
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
