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 |
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 |