Date: Tue, 30 May 2017 13:20:46 -0700
From: Karl Czajkowski <karlcz@isi.edu>
To: Rick Otten <rottenwindfish@gmail.com>
Cc: "Kevin.Hughes@uk.fujitsu.com" <Kevin.Hughes@uk.fujitsu.com>,
        "pgsql-performa." <pgsql-performance@postgresql.org>
Subject: Re: Client Server performance & UDS
Message-ID: <20170530202046.GE7575@moraine.isi.edu>
References: 
 <d9852308baee4c33aa11b4b1d33c8dc3@R01UKEXCASM123.r01.fujitsu.local>
 <CAMAYy4J1CrDfvTdSpx9zZ-aZ5W=AJmOPKBTRBhg9V69G7B_sjw@mail.gmail.com>
 <da3dc4593d12498187a6429e39340185@R01UKEXCASM123.r01.fujitsu.local>
 <CAMAYy4K+a8E0sWrDY-1Zhp8WPM_89enkHq07wqx-XsrgjBhm3g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAMAYy4K+a8E0sWrDY-1Zhp8WPM_89enkHq07wqx-XsrgjBhm3g@mail.gmail.com>
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

On May 30, Rick Otten modulated:

> If your clients are keeping persistent connections open to the
> database, and the latency you are experiencing is within the
> transaction itself, you might look at disk I/O for your WAL (write
> ahead logs) and take a closer look at WAL and checkpoint tuning.
> 

Also, if you are doing similar operations over and over with literal
data in them, you may have more query planner overhead per transaction
than if you prepared statements when opening the persistent connection
and then simply executed the statements over and over with different
parameters for each request.


Karl


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