On Sun, 14 Apr 2002, Barry Lind wrote: > But since the syntax for prepare is: PREPARE <name> AS <statement> you > can't easily reuse sql prepared by other PreparedStatement objects since > you don't know if the sql you are about to execute has or has not yet > been prepared or what <name> was used in that prepare. Thus you will > always need to do a new prepare. (This only is true if the driver is > trying to automatically use PREPARE/EXECUTE, which was the senario I was > talking about).
Well, there are some ugly tricks you could build into the driver to allow it to effectively use a PREPAREd statement with multiple, identical PreparedStatement objects (basically, via the driver caching various things and identifying PreparedStatements created with the same SQL), but it's messy enough and has some problems hard enough to resolve that I can't actually see this being practical. I was actually just wanting to point out that this is where automatic caching on the server shines. > >>If it only is used once, it will actually perform worse.... > > I didn't say it would be much worse, but it won't be faster than not > using PREPARE. Well, if it's not faster, that's fine. If it's worse, that's not so fine, because as you point out there's really no way for the driver to know whether a PreparedStatement is being used just for speed (multiple queries with one instance) or security (on query, but with parameters). > I am just pointing out that I don't think the driver > can behind the scenes use this capability automatically. Well, if there's little or no performance impact, I would say that the driver should always use this capability with PreparedStatement objects. If there is a performance impact, perhaps a property could turn it on and off? cjs -- Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
