Re: DBD::Pg performance bites compared to DBD::mysql?

From: "Greg Sabino Mullane" <greg(at)turnstep(dot)com>
To: pgsql-interfaces(at)postgresql(dot)org
Cc: gsstark(at)mit(dot)edu
Subject: Re: DBD::Pg performance bites compared to DBD::mysql?
Date: 2005-06-15 02:17:44
Message-ID: 8b2e8b9f285b6431df744927947cdfd9@biglumber.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)turnstep(dot)com
PGP Key: 0x14964AC8 200506142215
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8

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

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

In response to

Browse pgsql-interfaces by date

  From Date Subject
Next Message Jeff Eckermann 2005-06-15 15:15:21 Re: users/users groups management from MS Access front-end
Previous Message Zlatko Matić 2005-06-14 22:31:51 users/users groups management from MS Access front-end