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

From Greg Sabino Mullane
Subject Re: DBD::Pg performance bites compared to DBD::mysql?
Date
Msg-id 8b2e8b9f285b6431df744927947cdfd9@biglumber.com
Whole thread Raw
In response to Re: DBD::Pg performance bites compared to DBD::mysql?  (Greg Stark <gsstark@mit.edu>)
List pgsql-interfaces
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> 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?

We're not making any extra round trips per se, but we are not taking advantage of
the fact that we can know up front that the statement will not take any
parameters, and we can avoid parsing it for placeholders. My current idea is to treat
do(statement,args) as it currently is (sent to prepare/execute using PQexec (<7.4) or
PQexecParams (newer servers)), but to make a special fast path for simple do(statement)
that basically just throws the whole thing in a quick PQexec and returns. We've been
doing a lot of rewriting of stuff to support the new 7.4/8.0 v3 protocol stuff
such as PQprepare: now we can start the optimizing. :)

> Or given your example maybe it even notices no result is needed and doesn't even
> wait for a response?

That would be a neat trick, but they are not doing that. I don't even think it's
currently possible to derive that information via DBI the way things are now. Would
make a nice long-term micro-optimization though. :)

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200506142215
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8

-----BEGIN PGP SIGNATURE-----

iD8DBQFCr4+uvJuQZxSWSsgRApw5AJ9g3tQfihVWj6yOV0sHp5/Md15r4QCgps0Y
f1j8nPU6EqioSh20tckBsE0=
=X4WB
-----END PGP SIGNATURE-----




pgsql-interfaces by date:

Previous
From: Zlatko Matić
Date:
Subject: users/users groups management from MS Access front-end
Next
From: Jeff Eckermann
Date:
Subject: Re: users/users groups management from MS Access front-end