Received: from malur.postgresql.org ([217.196.149.56])
 by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from
 <pgsql-interfaces-owner+M7058=pgsql-interfaces-ark@postgresql.org>)
 id 1X2g7G-0007lJ-TQ
 for pgsql-interfaces@arkaria.postgresql.org; Thu, 03 Jul 2014 12:27:55 +0000
Received: from localhost ([127.0.0.1] helo=postgresql.org)
 by malur.postgresql.org with smtp (Exim 4.80) (envelope-from
 <pgsql-interfaces-owner+M7058=pgsql-interfaces-ark@postgresql.org>)
 id 1X2g7G-0000uc-Bz
 for pgsql-interfaces@arkaria.postgresql.org; Thu, 03 Jul 2014 12:27:54 +0000
Received: from makus.postgresql.org ([2001:4800:1501:1::229])
 by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256)
 (Exim 4.80) (envelope-from <pavel.golub@gf.microolap.com>)
 id 1X2g7E-0000uR-BG
 for pgsql-interfaces@postgresql.org; Thu, 03 Jul 2014 12:27:52 +0000
Received: from mail-lb0-f178.google.com ([209.85.217.178])
 by makus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.80) (envelope-from <pavel.golub@gf.microolap.com>)
 id 1X2g7A-0004lu-CR
 for pgsql-interfaces@postgresql.org; Thu, 03 Jul 2014 12:27:50 +0000
Received: by mail-lb0-f178.google.com with SMTP id 10so101304lbg.9
 for <pgsql-interfaces@postgresql.org>; Thu, 03 Jul 2014 05:27:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:sender:from:date:reply-to:organization
 :message-id:to:cc:subject:in-reply-to:references:mime-version
 :content-type:content-transfer-encoding;
 bh=j0IyUFvsdqQw3+33xFXCxudHHRJf7wo5V6H6aIHXvcU=;
 b=BATWQiwyy8Gtk0bKjCJVk2GtAafyv3gYF1K95VKs/Nc0BK2p9G7AaDROmQ9HWjfmbE
 XGBrIFQxFLWyPkunsQrIZnWo+QKOIyKBoK4nMMj/IeXTTLJRu3gCItbNToeIRjScFjt7
 nimTkCkl8Se8nkrO5pBP+mydoRnvA7L1tXoYAnYeVrSbGPt8rOFwxDp2OmRUtqq0UIrX
 uoNMdN4zvMLZVg/ug+UaZhVO5Cny7NpUYcggruddylyZtE4fxsQWZ79VDy6HbYKeQYax
 D991MZ/Q73qRK9q/RFRxqWtZQnV9bsjxadsL7iFw6rfhgS8wvTenWnXGBmOQOs3W8NgE
 +t9w==
X-Gm-Message-State: 
 ALoCoQmq5zFLR3Nk+oeWsr3oWEoiGFQCdGwK9zsu99t2E+KxMJu80j0M08H4aKElCreeBNeRrarU
X-Received: by 10.112.155.103 with SMTP id vv7mr1363319lbb.62.1404390465214;
 Thu, 03 Jul 2014 05:27:45 -0700 (PDT)
Received: from u1.102.seti.kr.ua (132.198.pool.seti.kr.ua. [91.202.132.198])
 by mx.google.com with ESMTPSA id xv6sm1789312lab.21.2014.07.03.05.27.42
 for <multiple recipients>
 (version=TLSv1 cipher=RC4-SHA bits=128/128);
 Thu, 03 Jul 2014 05:27:43 -0700 (PDT)
From: Pavel Golub <pavel@microolap.com>
X-Google-Original-From: Pavel Golub <pavel@gf.microolap.com>
Date: Thu, 3 Jul 2014 15:27:49 +0300
Reply-To: Pavel Golub <pavel@gf.microolap.com>
Organization: Microolap
X-Priority: 3 (Normal)
Message-ID: <13210629610.20140703152749@gf.microolap.com>
To: James Duong <jamesd@simba.com>
CC: "pgsql-interfaces@postgresql.org" <pgsql-interfaces@postgresql.org>
Subject: Re: libpq single-row mode performance
In-Reply-To: 
 <59b2f266559a4a46835d2add16d80c39@DM2PR04MB589.namprd04.prod.outlook.com>
References: 
 <59b2f266559a4a46835d2add16d80c39@DM2PR04MB589.namprd04.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1251
Content-Transfer-Encoding: 8bit
X-Pg-Spam-Score: -1.2 (-)
List-Archive: <http://archives.postgresql.org/pgsql-interfaces>
List-Help: <mailto:majordomo@postgresql.org?body=help>
List-ID: <pgsql-interfaces.postgresql.org>
List-Owner: <mailto:pgsql-interfaces-owner@postgresql.org>
List-Post: <mailto:pgsql-interfaces@postgresql.org>
List-Subscribe: <mailto:majordomo@postgresql.org?body=sub%20pgsql-interfaces>
List-Unsubscribe: 
 <mailto:majordomo@postgresql.org?body=unsub%20pgsql-interfaces>
X-Mailing-List: pgsql-interfaces
Precedence: bulk
Sender: pgsql-interfaces-owner@postgresql.org

Hello, James.

You wrote:

JD> Hi,
JD>  
JD> I知 writing an app on top of libpq. To avoid running out of
JD> memory I知 using the single-row mode, but am finding the overhead in using this quite significant.
JD>  
JD> What I see is that ~60% of my application痴 run time when
JD> retrieving data is spent in calls to either PQgetResult() and
JD> PQclear(). I致e added a switch in my app to turn off single-row
JD> mode and the performance roughly doubles.
JD>  
JD> Would it be possible to optimize the single-row mode? For
JD> example, add an API call PQnextRow(PGConn*), which is only usable
JD> in single-row mode and will just update the existing result with
JD> the contents of the next row? This would let us avoid to overhead of:
JD> 1.       Malloc段ng a PGResult and initializing its defaults.
JD> 2.       Copying the column metadata to the new results.
JD> 3.       Possibly we can avoid malloc段ng cell data if the next
JD> row has cells the same size or smaller than a previous row, though
JD> I知 not sure of the internals here.
JD> 4.       Release memory with PQclear().
JD>  
JD> James Duong | Senior Computer Scientist | Simba Technologies Inc.
JD> Tel +1.604.633.0008 ext. 120 | Fax +1.604.633.0004 | jamesd@simba.com
JD>  
JD> 938 West 8th Avenue | Vancouver, BC | Canada | V5Z 1E5
JD> The Data Access and Analytics Experts  |  www.simba.com 
JD>  
JD>                 
JD>  
JD> This email message is for the sole use of the intended
JD> recipient(s) and may contain confidential and privileged
JD> information.  Any unauthorized review, use, disclosure, or
JD> distribution is prohibited.  If you are not the intended
JD> recipient, please contact the sender by reply email and destroy
JD> all copies of the original message.  Thank you.
JD>  

Good idea. +1 from me. Should we send this message to pg-hackers as
well?

-- 
With best wishes,
 Pavel                          mailto:pavel@gf.microolap.com



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