On 10/09/2014 10:39 PM, Fabien COELHO wrote:
>> One thing bothers me with the log format. Here's an example:
>>
>>> 0 81 4621 0 1412881037 912698 3005
>>> 0 82 6173 0 1412881037 914578 4304
>>> 0 83 skipped 0 1412881037 914578 5217
>>> 0 83 skipped 0 1412881037 914578 5099
>>> 0 83 4722 0 1412881037 916203 3108
>>> 0 84 4142 0 1412881037 918023 2333
>>> 0 85 2465 0 1412881037 919759 740
>>
>> Note how the transaction counter is not incremented for skipped transactions.
>> That's understandable, since we're not including skipped transactions in the
>> number of transactions executed, but it means that the skipped transactions
>> don't have a unique ID. That's annoying.
>
> Indeed. As transactions were not done, it does not make much sense to
> identify them. Otherwise it should report "intended" transactions and
> "performed" transactions, which would not help clarify the matter much.
>
> My idea of "skipped" transactions, which are not transactions as such, is
> just a health quality measurement for both the throttling process and the
> database latency, so I would really let it as it is.
Hmm. I wonder if this is going to be a problem for programs that might
try to load the log file into a database table. No using transaction ID
as a unique key. Then again, you'll have to somehow deal with "skipped"
anyway.
>> Here's a new version of the patch. I'll sleep over it before committing, but
>> I think it's fine now, except maybe for the unique ID thing.
>
> I saw a typo in a comment: "lateny" -> "latency". Otherwise it looks ok,
> and the documentation seems indeed clearer than before.
Ok, committed after a few more typo-fixes.
Greg Smith, I'd still appreciate it if you could take a look at this, to
check how this will work for pgbench-tools.
- Heikki
