Re: pgbench - extend initialization phase control
Fabien COELHO <coelho@cri.ensmp.fr>
From: Fabien COELHO <coelho@cri.ensmp.fr>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: btkimurayuzk <btkimurayuzk@oss.nttdata.com>,
btendouan <btendouan@oss.nttdata.com>,
"ibrar.ahmad@gmail.com:" <pgsql-hackers@lists.postgresql.org>
Date: 2019-11-07T09:35:31Z
Lists: pgsql-hackers
Attachments
- pgbench-check-init-1.patch (text/x-diff) patch
Hello Masao-san, >> I do not think that this is desirable. It would be a regression, and >> allowing a no-op is not an issue in anyway. > > Why is that regression, you think? Because "pgbench -I ' d'" currently works and it would cease to work after the patch. > I think that's an oversight. If I'm missing something and accepting a > blank character as no-op in also checkInitSteps() is really necessary > for some reasons, which should be documented. But, if so, another > question is; why should only blank character be treated as no-op, in > checkInitSteps()? The idea is to have one character that can be substituted to remove any operation. On principle, allowing a no-op character, whatever the choice, is a good idea, because it means that the caller can take advantage of that if need be. I think that the actual oversight is that the checkInitSteps should be called at the beginning of processing initialization steps rather than while processing -I, because currently other places modify the initialization string (no-vacuum, foreign key) and thus are not checked. I agree that it should be documented. Attached patch adds a doc and moves the check where it should be, and modifies a test with an explicit no-op space initialization step. -- Fabien.
Commits
-
Add query cancellation capabilities in pgbench init phase
- 1d468b9ad81b 13.0 landed
-
Add "G" (server-side data generation) as an initialization step in pgbench.
- a386942bd29b 13.0 landed