X-Original-To: pgsql-interfaces-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id E400F5289D for ; Tue, 14 Jun 2005 23:17:41 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 47614-09 for ; Wed, 15 Jun 2005 02:17:40 +0000 (GMT) Received: from biglumber.com (biglumber.com [207.228.252.42]) by svr1.postgresql.org (Postfix) with SMTP id 227BC52889 for ; Tue, 14 Jun 2005 23:17:39 -0300 (ADT) Received: (qmail 15794 invoked from network); 15 Jun 2005 02:17:44 -0000 Received: from unknown (HELO localhost) (207.228.252.42) by 0 with SMTP; 15 Jun 2005 02:17:44 -0000 From: "Greg Sabino Mullane" To: pgsql-interfaces@postgresql.org Cc: gsstark@mit.edu Cc: gsstark@mit.edu Subject: Re: DBD::Pg performance bites compared to DBD::mysql? X-PGP-Key: 2529 DF6A B8F7 9407 E944 45B4 BC9B 9067 1496 4AC8 X-Request-PGP: http://www.biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 In-Reply-To: <87u0k11lpv.fsf@stark.xeocode.com> Date: Wed, 15 Jun 2005 02:17:44 -0000 X-Mailer: JoyMail 1.48 Message-ID: <8b2e8b9f285b6431df744927947cdfd9@biglumber.com> X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.13 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200506/42 X-Sequence-Number: 5610 -----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-----