Re: [HACKERS] Fwd: [DOCS] pgbench doc typos

2016-02-01 Thread Fujii Masao
On Wed, Jan 27, 2016 at 8:32 PM, Erik Rijkers  wrote:
> On 2016-01-27 11:06, Erik Rijkers wrote:
>>
>> Two trivial changes to  doc/src/sgml/ref/pgbench.sgml

-   Here is example outputs:
+   Here is example output:

"Here are example outputs" is better?
In 9.4 document, that description was used for the example outputs
of per-transaction logging.

> I did not understand this sentence:
>
>"Notice that while the plain (unaggregated) log file contains index
>of the custom script files, the aggregated log does not."
>
> "contains index"?  what does that mean?
>
> Not understanding, I have not changed it. I think it could be made more
> clear.

What about the following?


When multiple custom script files are specified with -f option,
while the plain (unaggregated) log file contains file_no field
which identifies which script file is used, the aggregated log does not.
Therefore if you need per script data, --aggregate-interval option
should not be specified and you need to aggregate the data on your own
from the plain log file.


BTW, I found another problem in pgbench.sgml. skipped_transactions is
documented as the last field of the plain log, but the format of the log
doesn't include that as follows.

client_id transaction_no time file_no time_epoch time_us [schedule_lag]

Regards,

-- 
Fujii Masao


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Fwd: [DOCS] pgbench doc typos

2016-01-27 Thread Erik Rijkers

On 2016-01-27 11:06, Erik Rijkers wrote:

Two trivial changes to  doc/src/sgml/ref/pgbench.sgml


Sorry - now attached.

Erik Rijkers

--- ./doc/src/sgml/ref/pgbench.sgml.orig	2016-01-27 12:29:16.857488633 +0100
+++ ./doc/src/sgml/ref/pgbench.sgml	2016-01-27 12:30:09.643862616 +0100
@@ -1056,7 +1056,7 @@
  0 84 4142 0 1412881037 918023 2333
  0 85 2465 0 1412881037 919759 740
 
-   In this example, transaction 82 was late, because it's latency (6.173 ms) was
+   In this example, transaction 82 was late, because its latency (6.173 ms) was
over the 5 ms limit. The next two transactions were skipped, because they
were already late before they were even started.
   
@@ -1097,7 +1097,7 @@
   
 
   
-   Here is example outputs:
+   Here is example output:
 
 1345828501 5601 1542744 483552416 61 2573
 1345828503 7884 1979812 565806736 60 1479

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers