Active Entries
- 1: Surge Pricing for Grocery Stores is a Disaster Only Psychopath MBAs Could Love
- 2: Antarctica Day 7: Swimming In the Antaractic Seas
- 3: Restarted my yoga classes, and I discovered I'm a total wreck
- 4: Antarctica: Getting To the Boat and the Disaster That Awaited
- 5: The Enshittification of All That Lives
- 6: How the green energy discourse resembles queer theory
- 7: Tori's Sake & Grill (restaurant, review)
- 8: I'm Not Always Sure I Trust My ADHD Diagonosis
- 9: You can't call it "Moral Injury" when your "morals" are monstrous
- 10: Ebay vs Newmark: You're all just cogs. Accept it. There is no joy in it, but you have no choice.
Style Credit
- Base style: ColorSide by
- Theme: NNWM 2010 Fresh by
Expand Cut Tags
No cut tags
no subject
Date: 2009-09-30 11:37 pm (UTC)Basically:
It's constant time if you have btree indexes for the primary key. Don't use a hash index, even though it might make otherwise sense for non-contiguous data. The MySQL compiler should realize that this is a simple btree lookup, and not even bother scanning. You *can* combine the two aggregate functions into a single query using a GROUP BY clause on a calculated field...but don't. It's horribly inefficient for large tables. Just use the separate queries above, which are optimized into simple index lookups:
If you want it all in a single DB call, use a stored procedure -- then you can just call the stored procedure with the itemid in question (this is what I recommend):
Hope this helps somewhat.
(I actually tested all of the above code, using a test items table that had an INT "id" field and a "content" field, with the first 10 prime numbers as the id's and the first ten letters as the content, on MySQL 5.0.)