On Feb 17, 2012, at 11:05 AM, Greg Sabino Mullane wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > >> query 2 is at least an order of magnitude slower than query 1 > > To follow up on this, the current best practice for handling this > is to prepare two statements, and have your app use the correct one. > One could be prepared with pg_server_prepare=0, and one as normal.
Now that I know the reason behind this, thanks to all of you, I have decided to stick with inline params `LIKE $q` instead of bind values. I am not too worried about SQL attacks, and the above strategy works well without having to toggle `pg_server_prepare`. Also, I do expect the query to run often, but as the frontend is a web app, it will be called in separate sessions... so, think many reloads of the same page as opposed to one page request firing many instances of the same query. Many thanks Greg. > > That's a general setup that may not apply to your exact situation, > but we can't tell what your actual arguments are and how often you > call them based on your example. The idea is to create different > statements (perhaps even more than two) to account for the different > plans that are created, based on the information available to the > planner. Your app can then pick the appropriate one to use based on > what parameters are being sent. > > - -- > Greg Sabino Mullane g...@turnstep.com > End Point Corporation http://www.endpoint.com/ > PGP Key: 0x14964AC8 201202171158 > http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 > -----BEGIN PGP SIGNATURE----- > > iEYEAREDAAYFAk8+iN4ACgkQvJuQZxSWSsjZ0ACdG+U7Ux7mdNs8NQ2W/8J/HYPA > i1kAn0FSO5ukuG6mvbIuboq2iRvAlg2e > =S3U1 > -----END PGP SIGNATURE----- > >
