subqueries do not get cached


…the cache is not used for queries of the following types:

* Prepared statements
* Queries that are a subquery of an outer query
* Queries executed within the body of a stored function or trigger


For certain cases, a correlated subquery is optimized. For example:

val IN (SELECT key_val FROM tbl_name WHERE correlated_condition)

Otherwise, they are inefficient and likely to be slow. Rewriting the query as a join might improve performance.

I have 5 nested views… from 1 to 4, I have GROUP BY, ORDER BY, JOIN of the data over themselfs and other amenities… and on a ~2milion rows table, it doesn’t take more than 14 seconds…

the last view… has a subquery… evaluating the data related to the “currently evaluated row”, looking on the same table for values of “the same group”… and it gets DAMN SLOW… cause the “query cache” mechanism of MySQL does not kick in

k, tomorrow morning I go for the rewriting… I’ll create a VIEW about the data I need to be correlated, and I’ll JOIN it… let’s see 🙂

mappe per cellulari

Vodafone Wayfinder Open Source Software

Vodafone Demonstrates Commitment to Open Source Innovation

15 July 2010
Group Press Releases (2010)

mi sono stupito pure io…
visto che il nostro CTO, e meta’ del management, arriva da M$

trovate i sorci su

p.s. (giusto per fare chiarezza) hanno deciso di rilasciarlo dopo che hanno mandato a casa tutti gli sviluppatori e chiuso l’ufficio di Cambridge… NdR.

piu’ leggo

e piu’ mi innamoro del kernel 😀

/** pcmcia_request_irq
 * Request_irq() reserves an irq for this client.
 * Also, since Linux only reserves irq's when they are actually
 * hooked, we don't guarantee that an irq will still be available
 * when the configuration is locked.  Now that I think about it,
 * there might be a way to fix this using a dummy handler.

tratto da drivers/pcmcia/pcmcia_resource.c +709

k… ora capisco tutto l’astio che Ale ha per l’architettura x86…