On Fri, Apr 7, 2017 at 12:54 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
>> On 04/07/2017 06:31 PM, Merlin Moncure wrote:
>>> I think your math is off. Looking at your attachments, planning time
>>> is 0.056ms, not 0.56ms. This is in no way relevant to performance on
>>> the order of your measured TPS. How are you measuring TPS?
>
>> Not sure where did you get the 0.056ms?
>
> I don't see that either, but:
>
>> What I see is this in the 9.3 explains:
>> Total runtime: 0.246 ms
>> and this in those from 9.6:
>> Planning time: 0.396 ms
>> Execution time: 0.181 ms
>> That is roughly 0.25ms vs. 0.6ms (0.4+0.2), as reported by Prakash.
>
> 9.3's EXPLAIN did not measure planning time at all. The "Total runtime"
> it reports corresponds to "Execution time" in the newer version. So
> these numbers indicate that 9.6 is significantly *faster*, not slower,
> than 9.3, at least so far as execution of this one example is concerned.
>
> The OP may well be having some performance issue with 9.6, but the
> presented material completely fails to demonstrate it.
This smells like a problem with the test execution environment itself.
OP (if on linux), try:
pgbench -n -f <(echo "select * from subscriber where s_id = 100") -c 4 -T 10
...where pgbench is run from the database server (if pgbench is not in
the default path, you may have to qualify it). This should give
apples to apples comparison, or at least rule out certain
environmental considerations like the network stack.
If your client is running on windows, one place to look is the TCP
stack. In my experience tcp configuration issues are much more common
on windows. On any reasonably modern hardware can handle thousands
and thousands of transactions per second for simple indexed select.
merlin
