Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 422AC133798E for ; Thu, 9 Dec 2010 02:39:46 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 52392-03 for ; Thu, 9 Dec 2010 06:39:39 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from nm5-vm0.bullet.mail.ac4.yahoo.com (nm5-vm0.bullet.mail.ac4.yahoo.com [98.139.52.68]) by mail.postgresql.org (Postfix) with SMTP id A3DDA1336B42 for ; Thu, 9 Dec 2010 02:39:38 -0400 (AST) Received: from [98.139.52.193] by nm5.bullet.mail.ac4.yahoo.com with NNFMP; 09 Dec 2010 06:39:37 -0000 Received: from [98.139.52.128] by tm6.bullet.mail.ac4.yahoo.com with NNFMP; 09 Dec 2010 06:39:37 -0000 Received: from [127.0.0.1] by omp1011.mail.ac4.yahoo.com with NNFMP; 09 Dec 2010 06:39:37 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 126457.34035.bm@omp1011.mail.ac4.yahoo.com Received: (qmail 71486 invoked by uid 60001); 9 Dec 2010 06:39:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1291876776; bh=7lZ17roz4P1sZBk0OK3AYAzw/kRuoni1Yo57dXTGMqQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=pPUOJCWLQuUoq2wQkrqkA3bYU7RGbLtsKjVIbyj41D7Rl9xpnbUIg2hNReLTEyqootYro7jdUISHXpSB5VE+RWdhDqAYWkuTdO5iEdvA2R8QgrwPDaCtJGd66Z+mgjhjhvbLCIgPt9J/MI+3gYAopj7hB0pE8C5EP1xxhT38p0I= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=qoV00xSgthIc5fQI/Zj0GLL4k3+kVSbswKgpmJH1WrFcCDHLh0Fa0KEGkUR97rHa/n8bt89Dc2s0oT/rp0O6ZuocxtgS5FR3P0KVGBdYA66Z4OlX7ka6usqs6x1TybCkZFE6Pf39H0fQ86hl54jQ7Ho4JhZRnbpiXkJgmaqZxW8=; Message-ID: <957894.71040.qm@web65406.mail.ac4.yahoo.com> X-YMail-OSG: cKEs5yAVM1m4rvU9jQYJmR0Qz2uL7Htq_wvXIXCxETslcXI _DDkRWaUCIQciidYD0jqHGJm161CaOtk0YCUge0dms92OsBELf9hhTsrm4AD AUlGNwTaixnGTdKb0R6.QbMqpjtvFSaJoZ2gD.w9Mf1iPaRuas_Siiy0kv8p ZZVHGihogbdKMkozXVjbwNZacQAHnfEnaaPr2oMdGG_hStLPV0Vncp_RJuWF Gx_IM._SuSC26Fa3Ts_eFqnB6RvI_AL8UKfheczsQK4hI0BrN78ApH7Qz7uX .nkZuxEb9qnrSj5b96uKjM8MAz9FJCn6OUopYEXv_tFpV.ev2gqzy0kUouai ATptL5YWpqx32Gf9yRR8rDpSmEOQTwcXlpLBGJxV1VCSQIQ-- Received: from [194.237.142.20] by web65406.mail.ac4.yahoo.com via HTTP; Wed, 08 Dec 2010 22:39:36 PST X-Mailer: YahooMailRC/553 YahooMailWebService/0.8.107.285259 References: <772237.64789.qm@web65408.mail.ac4.yahoo.com> <254429.23607.qm@web65410.mail.ac4.yahoo.com> Date: Wed, 8 Dec 2010 22:39:36 -0800 (PST) From: Divakar Singh Subject: Re: libpq vs ODBC To: Alex Goncharov Cc: alex-goncharov@comcast.net, pgsql-performance@postgresql.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1500843935-1291876776=:71040" X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.022 tagged_above=-10 required=5 tests=BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1.929, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RFC_ABUSE_POST=0.001, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201012/141 X-Sequence-Number: 41593 --0-1500843935-1291876776=:71040 Content-Type: text/plain; charset=us-ascii hmm If I understand it correctly you argument is valid from performance point of view. But in practical scenarios, it would make more sense to do ODBC if the difference is only 5% or so, because it opens up so many choices of databases for me. Do we have some published data in this area. Best Regards, Divakar ________________________________ From: Alex Goncharov To: Divakar Singh Cc: alex-goncharov@comcast.net; pgsql-performance@postgresql.org Sent: Thu, December 9, 2010 11:21:26 AM Subject: Re: [PERFORM] libpq vs ODBC ,--- You/Divakar (Wed, 8 Dec 2010 21:17:22 -0800 (PST)) ----* | So it means there will be visible impact if the nature of DB interaction is DB | insert/select. We do that mostly in my app. You can't say a "visible impact" unless you can measure it in your specific application. Let's say ODBC takes 10 times of .001 sec for libpq. Is this a "visible impact"? | Performance difference would be negligible if the query is server intensive | where execution time is far more than time taken by e.g. communication interface | or transaction handling. | Am I right? You've got to measure -- there are too many variables to give you the answer you are trying to get. To a different question, "Would I use ODBC to work with PostgreSQL if I had the option of using libpq?", I'd certainly answer, "No". You'd need to have the option of using libpq, though. ODBC takes care of a lot of difficult details for you, and libpq's higher performance may turn out to be a loss for you, in your specific situation. -- Alex -- alex-goncharov@comcast.net -- -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance --0-1500843935-1291876776=:71040 Content-Type: text/html; charset=us-ascii
hmm
If I understand it correctly you argument is valid from performance point of view.
But in practical scenarios, it would make more sense to do ODBC if the difference is only 5% or so, because it opens up so many choices of databases for me.
Do we have some published data in this area.

 
Best Regards,
Divakar



From: Alex Goncharov <alex-goncharov@comcast.net>
To: Divakar Singh <dpsmails@yahoo.com>
Cc: alex-goncharov@comcast.net; pgsql-performance@postgresql.org
Sent: Thu, December 9, 2010 11:21:26 AM
Subject: Re: [PERFORM] libpq vs ODBC

,--- You/Divakar (Wed, 8 Dec 2010 21:17:22 -0800 (PST)) ----*
| So it means there will be visible impact if the nature of DB interaction is DB
| insert/select. We do that mostly in my app.

You can't say a "visible impact" unless you can measure it in your
specific application.

Let's say ODBC takes 10 times of .001 sec for libpq.  Is this a
"visible impact"?

| Performance difference would be negligible if the query is server intensive
| where execution time is far more than time taken by e.g. communication interface
| or transaction handling.
| Am I right?

You've got to measure -- there are too many variables to give you the
answer you are trying to get.

To a different question, "Would I use ODBC to work with PostgreSQL if
I had the option of using libpq?", I'd certainly answer, "No".

You'd need to have the option of using libpq, though.  ODBC takes care
of a lot of difficult details for you, and libpq's higher performance
may turn out to be a loss for you, in your specific situation.

-- Alex -- alex-goncharov@comcast.net --


--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

--0-1500843935-1291876776=:71040--