Re: DBD::Pg performance bites compared to DBD::mysql? - Mailing list pgsql-interfaces

From Greg Stark
Subject Re: DBD::Pg performance bites compared to DBD::mysql?
Date
Msg-id 87u0k11lpv.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: DBD::Pg performance bites compared to DBD::mysql?  ("Greg Sabino Mullane" <greg@turnstep.com>)
Responses Re: DBD::Pg performance bites compared to DBD::mysql?  ("Greg Sabino Mullane" <greg@turnstep.com>)
List pgsql-interfaces
"Greg Sabino Mullane" <greg@turnstep.com> writes:

> I still maintain the original test is brain-dead, however. :) It was
> testing for "insert speed" by basically doing this:
> 
> for (1..1000) {
>         $dbh->do("INSERT INTO testtable(a,b) VALUES (1,2)");
> }
> 
> It's as if the people who wrote it *cough*mysql*cough* never heard
> of prepare/execute and did not read the DBI docs.


Sure but wouldn't that show up as more time spent in the server in the parser
and planner? I thought Tom was complaining that it was spending too much time
in the client not waiting on server responses.

I wonder if Postgres is being bitten by doing lots of extra round trips. Maybe
the MySQL driver detects when there are no placeholders and no parameters and
uses a different protocol method that only requires a single round trip? Or
given your example maybe it even notices no result is needed and doesn't even
wait for a response?

-- 
greg



pgsql-interfaces by date:

Previous
From: "Greg Sabino Mullane"
Date:
Subject: Re: DBD::Pg performance bites compared to DBD::mysql?
Next
From: Zlatko Matić
Date:
Subject: users/users groups management from MS Access front-end