Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization |
Дата | |
Msg-id | CA+TgmoaiWGOXHn51d-uCFd5CmTcskVFT6m2DZEiWog9SU0Vo8g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization
|
Список | pgsql-hackers |
On Wed, Aug 2, 2017 at 9:41 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Tue, Aug 1, 2017 at 9:49 PM, Masahiko Sawada <sawada.mshk@gmail.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
В списке pgsql-hackers по дате отправления: