philippe-daniel brin wrote:Basically, there is a resource/time overhead cost to "prepare" a statement in the DB Server; but that cost will be saved every time you run the statement once it's prepared while an unprepared statement will have less overhead but it will cost every time you run the statement.
Actually, academically speaking, that's not entirely true. A common practice is for database servers to cache the source text of SQL statements they receive and use the statement text as a hashtable key to the compiled statement, so that the bulk of the work: compiling the SQL and setting up context - is only done once. At least until the cache entry expires and gets purged. However, this only applies if the SQL statement is character-for-character identical to its previous version. So the overhead for the first "SELECT * FROM xyz WHERE post_date = '2010-07-03'" is going to be more than subsequent requests. However, a "SELECT * FROM xyz WHERE post_date = '2010-07-
05'" would not benefit. It would have to set up its own cached context.
This might seem to be a fairly useless thing to do, except that paged SQL fetches may use it (or a variant of it), as would periodic polling and other repeated requests. The cost of caching is quite low compared to cranking the whole thing up from scratch.
Some people, when well-known sources tell them that fire will burn them, don't put their hands in the fire.
Some people, being skeptical, will put their hands in the fire, get burned, and learn not to put their hands in the fire.
And some people, believing that they know better than well-known sources, will claim it's a lie, put their hands in the fire, and continue to scream it's a lie even as their hands burn down to charred stumps.