Re: pgbench doc fix

From: Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>
To: coelho(at)cri(dot)ensmp(dot)fr
Cc: peter(dot)eisentraut(at)2ndquadrant(dot)com, 9erthalion6(at)gmail(dot)com, ishii(at)sraoss(dot)co(dot)jp, robertmhaas(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pgbench doc fix
Date: 2018-12-03 05:33:15
Message-ID: 20181203.143315.2134125635511306803.t-ishii@sraoss.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>>>> So I do not think a more precise wording harms. Maybe: "prepared: use
>>>>> extended query protocol with REUSED named prepared statements" would
>>>>> be even less slightly ambiguous.
>>>>
>>>> I like this. But maybe we can remove "named"?
>>>
>>> I also think it makes sense to adjust wording a bit here, and this
>>> version
>>> sounds good (taking into account the commentary about "named"). I'm
>>> moving this
>>> to the next CF, where the question would be if anyone from commiters
>>> can agree
>>> with this point.
>>
>> I don't see a concrete proposed patch here after the discussion.
>>
>> Reading the documentation again, we could go for much more detail
>> here.
>> For example, what's the point of having -M simple vs -M extended?
>
> They do not use the same libpq-level approach (PQsendQuery vs
> PQsendQueryParams), so they are not exercising the same type of
> client? Pgbench is also about testing libpq performance.

Yes, -M extended is pretty slow because for each query it needs to
send parse/bind/describe/execute messages. -M prepared is much faster
because for the second and subsequent iterations of query, it does not
need to execute parse analysis, which means not only less message are
exchanged but parse analysis are omitted for the second and subsequent
query iterations.

Here are quick test results using pgbench -S -M $mode -c 10 -T 30,
where $mode is "simple", "extended" or "prepared" on my Ubuntu 18
laptop. The TPS numbers are average on each 3 trials for "execuding
connections establishing".

simpe:
48804.8383 TPS

extended:
39735.4278 TPS

prepared:
83459.2293 TPS

So "prepared" is roughly 2x faster than "extended".

Based on this, I would suggest to modify exiting descriptions in
pgbench doc regarding "-M querymode":

From:
-------------------------------------------------------------------
-M querymode
--protocol=querymode

Protocol to use for submitting queries to the server:

simple: use simple query protocol.

extended: use extended query protocol.

prepared: use extended query protocol with prepared statements.
-------------------------------------------------------------------

To:
-------------------------------------------------------------------
-M querymode
--protocol=querymode

Protocol to use for submitting queries to the server:

simple: use simple query protocol.

extended: use extended query protocol.

prepared: use extended query protocol with prepared statements.

Because in "prepared" mode pgbench reuses the parse analysis
result for the second and subsequent query iteration, pgbench runs
faster in the prepared mode than in other modes.
-------------------------------------------------------------------

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp

Attachment Content-Type Size
pgbench-doc.diff text/x-patch 873 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2018-12-03 05:35:06 Re: "could not reattach to shared memory" on buildfarm member dory
Previous Message John Naylor 2018-12-03 05:30:12 Re: WIP: Avoid creation of the free space map for small tables