Re: UPDATE statements causing me grief!

2011-10-07 Thread Puneet Kishor
in the test site, and am refreshing the prod site. All the fancy tools notwithstanding, human mind can handle only so much complexity. Which is why drivers shouldn't be allowed to text (or talk on the phone, or shave, or check their lipstick, or...). Lives are at stake here. -- Puneet Kishor

same query, two different approaches, vastly different performance

2012-02-13 Thread Puneet Kishor
yes, I have tried it with query 2 before query 1 to eliminate caching. There is a difference, but I don't know why, so would love hear an explanation. Many tia, -- Puneet Kishor

Re: same query, two different approaches, vastly different performance

2012-02-13 Thread Puneet Kishor
h a postfix wildcard search. One, I prepare with the search term embedded in the query. The other is prepared with a bind variable and the search term is added during $sth->execute. The first one uses the index. The second does a full-table scan. Strange, but true. -- Puneet Kishor

Re: same query, two different approaches, vastly different performance

2012-02-13 Thread Puneet Kishor
because, if true, then it is a strike against statements prepared with bind values. > > > On Feb 13, 2012, at 19:07, Puneet Kishor wrote: > > > On Feb 13, 2012, at 6:57 PM, David Nicol wrote: > >> did you find >> >> http://stackoverflow.com/questions/1

Re: same query, two different approaches, vastly different performance

2012-02-13 Thread Puneet Kishor
>> inline args. >> > > > > a... that makes sense. I would like to confirm this, because, if true, > then it is a strike against statements prepared with bind values. > > >> >> >> On Feb 13, 2012, at 19:07, Puneet Kishor wrote: >

Re: same query, two different approaches, vastly different performance

2012-02-13 Thread Puneet Kishor
ok. I am completely lost here. On Feb 13, 2012, at 8:10 PM, David Nicol wrote: > On Mon, Feb 13, 2012 at 7:16 PM, Puneet Kishor > >> >> >> a... that makes sense. I would like to confirm this, because, if true, >> then it is a strike against statem

Re: same query, two different approaches, vastly different performance

2012-02-17 Thread Puneet Kishor
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 hav

asynchronous mode error 2000

2011-07-15 Thread Mr. Puneet Kishor
I have a MySQL/Perl Dancer [http://perldancer.org] powered web app. Actually, two web apps. The user goes to app A [http://teststrata.geology.wisc.edu/macromap] which serves up a Google maps base layer. On document ready, it makes two jQuery ajax calls to app B [http://teststrata.geology.wisc.e

DBD::Pg closes connection "unexpectedly"

2011-09-03 Thread Mr. Puneet Kishor
I am on Mac OS X Lion with Pg 9.0.x, Perl 5.14.1, and the latest iterations of DBI and DBD::Pg. My code is pretty straightforward my $dbh = DBI->connect("dbi:Pg:dbname=macromap;host=localhost;port=5432", 'postgres', 'postgres'); my $sth = $dbh->prepare( .. ); $sth->execute; while

Re: DBD::Pg closes connection "unexpectedly"

2011-09-03 Thread Mr. Puneet Kishor
On Sep 3, 2011, at 9:46 PM, David E. Wheeler wrote: > On Sep 3, 2011, at 7:27 PM, Mr. Puneet Kishor wrote: > >> I am on Mac OS X Lion with Pg 9.0.x, Perl 5.14.1, and the latest iterations >> of DBI and DBD::Pg. My code is pretty straightforward >> >> my $dbh

Re: regarding DBI module not working windows 2010

2012-01-15 Thread Mr. Puneet Kishor
of them. Just make sure the perl you are using is using the modules that match it. -- Puneet Kishor