sudden drop in statement turnaround latency -- yay!.
От | Merlin Moncure |
---|---|
Тема | sudden drop in statement turnaround latency -- yay!. |
Дата | |
Msg-id | 6EE64EF3AB31D5448D0007DD34EEB3412A758A@Herge.rcsinc.local обсуждение исходный текст |
Ответы |
Re: sudden drop in statement turnaround latency -- yay!.
|
Список | 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 application: 0.000278866 sec: data1_read_key_item_vendor_file_0 params: $1=005988 $2=002255 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 $2=000117 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 $2=000117 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? Merlin
В списке pgsql-performance по дате отправления: