On Dec 29, 4:55 am, Iñaki Baz Castillo <[email protected]> wrote: > Hi, I'm trying to take advantage of postgres native prepared statements using > 'pg' driver. > > 'doc' field is "character varying(64)" and 'doc_uri' is "character > varying(128)". > > I prepare my query as follows: > > 1) Using bound variables: > > ps = DB[table]. \ > filter(:user => :$n1, :doc_uri => :$n2). \ > select(:doc, :etag). \ > prepare(:first, :my_ps) > > 2) Using (or trying to use) native prepared statements: > > ps = DB[table]. \ > filter(:user => :$n1__varchar, :doc_uri => :$n2__varchar). \ > select(:doc, :etag). \ > prepare(:first, :my_ps) > > I do 10000 equal queries in localhost (Postgres 8.4) and I see no difference > at all in the benchmarks for both cases. Postgres database logging is > disabled. > > I've also tryed: > > filter(:user => :"$n1__varchar(64)", :doc_uri => :"$n2__varchar(128)") > > with same result. > > Unfortunatelly by enabling the Postgres log to check what is happening I see > no difference between both cases. I know the second case is doing "something" > as if I set ":user => :$n1__integer" then postgres complains. > > Do I miss something? Perhaps the query is so simple that I get no difference > between using bound variables and native prepared statements? > > Thanks a lot.
Blindly using prepared statements for performance reasons is short- sighted, at least on most of the open source databases (e.g. Oracle may be different). With Sequel, I recommend prepared statements only be used if a bottleneck is encountered, and benchmarking should be done to make sure that using prepared statements is faster for that case. Jeremy -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en.
