From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pgbench: Skipping the creating primary keys after initialization |
Date: | 2017-08-02 14:04:23 |
Message-ID: | CA+TgmoaiWGOXHn51d-uCFd5CmTcskVFT6m2DZEiWog9SU0Vo8g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Aug 2, 2017 at 9:41 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Tue, Aug 1, 2017 at 9:49 PM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>>> I'd like to propose a new option -I for pgbench command which skips
>>> the creating primary keys after initialized tables.
>
>> I support adding an option for this, but I propose that we just make
>> it a long-form option, similar to --log-prefix or --index-tablespace.
>
> 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.
I've actually wanted this exact thing multiple times: most recently,
to make a non-unique btree index instead of a unique one, and to make
a hash index instead of a btree one. I don't object to a modest
effort at coming up with a more general mechanism here, but I also
think the switch as proposed is something that would have met my real
needs on multiple occasions. I've probably had 10 different occasions
when I wanted all of the standard pgbench initialization *except for*
something different about the indexes.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-08-02 14:11:46 | Re: reload-through-the-top-parent switch the partition table |
Previous Message | Tatsuo Ishii | 2017-08-02 13:56:29 | Re: pgbench: Skipping the creating primary keys after initialization |