Hello Masao-san,
>> The benefit of controlling where begin/end actually occur is that it may
>> have an impact on performance, and it allows to check that.
>
> I still fail to understand the benefit of addition of () settings.
> Could you clarify what case () settings are useful for? You are
> thinking to execute all initialization SQL statements within
> single transaction, e.g., -I (dtgp), for some reasons?
Yep. Or anything else, including without (), to allow checking the
performance impact or non impact of transactions on the initialization
phase.
>>> When using ( and ) with the -I, the documentation should indicate that double
>>> quotes are required,
>>
>> Or single quotes, or backslash, if launch from the command line. I added a
>> mention of escaping or protection in the doc in that case.
>
> What about using, for example, b (BEGIN) and c (COMMIT) instead
> to avoid such restriction?
It is indeed possible. Using a open/close symmetric character ( (), {},
[]) looks more pleasing and allows to see easily whether everything is
properly closed. I switched to {} which does not generate the same quoting
issue in shell.
> I think that it's better to check whehter "v" is enclosed with () or not
> at the beginning of pgbench, and report an error if it is.
>
> Otherwise, if -I (dtgv) is specified, pgbench reports an error after
> time-consuming data generation is performed, and of course that data
> generation is rollbacked.
Patch v5 attached added a check for v inside (), although I'm not keen on
putting it there, and uses {} instead of ().
--
Fabien.
