sudden drop in statement turnaround latency -- yay!.

From: Merlin Moncure
Subject: sudden drop in statement turnaround latency -- yay!.
Date: ,
Msg-id: 6EE64EF3AB31D5448D0007DD34EEB3412A758A@Herge.rcsinc.local
(view: Whole thread, Raw)
Responses: Re: sudden drop in statement turnaround latency -- yay!.  (Tom Lane)
List: pgsql-performance

I took advantage of the holidays to update a production server (dual
Opteron on win2k) from an 11/16 build (about beta5 or so) to the latest
release candidate.  No configuration changes were made, just a binary
swap and a server stop/start.

I was shocked to see that statement latency dropped by a fairly large
margin.  Here is a log snippet taken as measured from the client

0.000278866 sec:  data1_read_key_item_vendor_file_0 params: $1=005988
0.00032731  sec:  data1_read_key_item_link_file_1 params: $1=005988
0.000327063 sec:  data1_read_key_bm_header_file_0 params: $1=008704
0.000304915 sec:  data1_read_key_item_vendor_file_0 params: $1=008704
0.00029838  sec:  data1_read_key_item_link_file_1 params: $1=008704
0.0003252   sec:  data1_read_key_bm_header_file_0 params: $1=000268
0.000274747 sec:  data1_read_key_item_vendor_file_0 params: $1=000268
0.000324275 sec:  data1_read_key_item_link_file_1 params: $1=000268

These are statements that are run (AFIK) the fastest possible way, which
is using prepared statements over parse/bind.  The previous latencies
usually varied between .0005 and .0007 sec, but never below .5 ms for a
index read.  Now, as demonstated by the log, I'm getting times less than
half that figure.  I benchmarked a transversal over a bill of materials
(several thousand statements) and noticed about a 40% reduction in time
to complete the operation.

I wonder exactly what and when this happened, has anybody else noticed a
similar change?


pgsql-performance by date:

From: Karl Vogel
Subject: Re: Why so much time difference with a same query/plan?
From: Tom Lane
Subject: Re: sudden drop in statement turnaround latency -- yay!.