Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization
Date
Msg-id 7643.1501689001@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization  (Robert Haas <robertmhaas@gmail.com>)
Responses 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>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] pgsql 10: hash indexes testing
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization