Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization
Дата
Msg-id 7643.1501689001@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization  (Robert Haas <robertmhaas@gmail.com>)
Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Aug 2, 2017 at 10:17 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Or in other words, this looks to me quite a bit like the hackery
>> that resulted in pgbench's -S and -N options, before we figured out
>> that making it scriptable was a better answer.

> But it's not very clear to me how we could make this case scriptable,

Well, I'm imagining that "-i" would essentially become a short form
of "-b initialize", as already happened for -S and -N, where the script
looks something like

drop table if exists pgbench_branches;
create table pgbench_branches ( bid int not null,bbalance int,filler char(88)
);
\load_data pgbench_branches [ other parameters to-be-determined ]
alter table pgbench_branches add primary key (bid);
... repeat for other tables ...

and we'd document that the same way we do for the existing built-in
scripts.  Then, if there's something you don't like about it, you
just paste the script into a file and edit to taste.

I'm sure there's complexities that would only become apparent when
someone tries to write the patch, but that seems to me like a better
foundation for this class of desires than extending the option set
with various one-off options having no discernible architecture.

> If you just want to create
> different/extra indexes, you can do that yourself.

Sure, but there's no end to the number of small variations on this
theme that somebody might want.  For example, we realized years ago
that the "filler" fields as-implemented don't really meet the intent
of the TPC-B spec (cf comment in the init() function).  If someone
comes along with a patch adding a "--really-tpc-b" option to change
the table declarations and/or data loading code to fix that, will we
take that patch?  What about one that wants all the id fields (not
just accounts.aid) to be bigint, or one that wants the balance fields
to be numeric?

You can say "let 'em set up the tables manually if they want that",
but I don't see why a nonstandard set of indexes is much different.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] pgsql 10: hash indexes testing
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization