Re: unexpected psql "feature"

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: unexpected psql "feature"
Дата
Msg-id alpine.DEB.2.20.1607140824400.1962@sto
обсуждение исходный текст
Ответ на Re: unexpected psql "feature"  ("David G. Johnston" <david.g.johnston@gmail.com>)
Ответы Re: unexpected psql "feature"  (Fabien COELHO <coelho@cri.ensmp.fr>)
Список 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.
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dilip Kumar
Дата:
Сообщение: Issue in pg_catalog.pg_indexes view definition
Следующее
От: Dilip Kumar
Дата:
Сообщение: Re: Issue in pg_catalog.pg_indexes view definition