| From: | Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> |
|---|---|
| To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
| Cc: | robertmhaas(at)gmail(dot)com, sawada(dot)mshk(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: pgbench: Skipping the creating primary keys after initialization |
| Date: | 2017-08-02 13:56:29 |
| Message-ID: | 20170802.225629.1328225685553197025.t-ishii@sraoss.co.jp |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> I think we could probably do without this ... if you want a non-default
> test setup, why do you need to use "pgbench -i" to create it?
>
> It's not that there's anything greatly wrong with this particular idea,
> it's just that pgbench has too many switches already, and omitting random
> subsets of the initialization actions doesn't seem like it contributes
> fundamental new benchmarking capability.
>
> I could get behind a proposal that generalized pgbench's "-i" behavior
> in some meaningful way. I wonder whether it would be possible to convert
> that behavior into a script. Some of what it does is just SQL commands
> with injected parameters, which pgbench does already. There's also
> data-loading actions, which could be converted to backslash commands
> perhaps. Then desires like this could be addressed by invoking a
> customized script instead of complicating pgbench's option set.
+1.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2017-08-02 14:04:23 | Re: pgbench: Skipping the creating primary keys after initialization |
| Previous Message | Tom Lane | 2017-08-02 13:41:58 | Re: pgbench: Skipping the creating primary keys after initialization |