Re: unexpected psql "feature" - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: unexpected psql "feature"
Date
Msg-id alpine.DEB.2.20.1607140824400.1962@sto
Whole thread Raw
In response to Re: unexpected psql "feature"  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: unexpected psql "feature"  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
Hello David,

> Why would you choose to execute "SELECT 1 \; SELECT 2;" instead of "SELECT
> 1; SELECT 2;"​ in a setup where the behavior of both strings is identical?
> Or, rather, how would they differ?

The answer is that at the protocol level the first one is one network
round trip with the server, the second is two.

The difference probably does not really matter that much for psql which is
more an interactive than a scripting tool.

However I'm really looking at that in the context of pgbench, which
exhibits the same behavior.

If you run a bench and have one round trip or several over a local
network, the latency is not the same. Consider a throttled read-only load
composed of 3 random selects, several rounds (so.sql) vs one (so2.sql):

  > pgbench -h server -T 100 -P 1 --rate 200 -c 2 -f so.sql -f so2.sql
  ...
  SQL script 1: so.sql
   - weight = 1 (targets 50.0% of total)
   - 10010 transactions (50.1% of total, tps = 100.101872)
   - latency average = 1.878 ms
   - latency stddev = 3.614 ms
  SQL script 2: so2.sql
   - weight = 1 (targets 50.0% of total)
   - 9954 transactions (49.9% of total, tps = 99.541861)
   - latency average = 1.089 ms
   - latency stddev = 3.022 ms

There is 0.8 ms latency reduction, that is a 40% difference. Standard
deviation is also significantly lower.

--
Fabien.
Attachment

pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Issue in pg_catalog.pg_indexes view definition
Next
From: Dilip Kumar
Date:
Subject: Re: Issue in pg_catalog.pg_indexes view definition