Re: pgbench: Skipping the creating primary keys after initialization

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(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-22 08:15:30
Message-ID: alpine.DEB.2.20.1708221009100.19265@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


>> Why not allow -I as a short option for --custom-initialize?
>
> Other options for similar purpose such as --foreign-keys also have
> only a long option. Since I think --custom-initialize option is in the
> same context as other options I didn't add short option to it for now.
> Because the options name is found by a prefix searching we can use a
> short name --cu for now.

Hmmm. I like short options:-)

> I'm inclined to remove the restriction so that we can specify
> --foreign-keys, --no-vacuum and --custom-initialize at the same time.

Ok. I favor that as well.

> I think a list of char would be better here rather than a single
> malloced string to remove particular initialization step easily.
> Thought?

My thought is not to bother with a list of char.

To remove a char from a string, I suggest to allow ' ' to stand for
nothing and be skipped, so that substituting a letter by space would
simply remove an initialization phase.

For adding, realloc & append.

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Aleksander Alekseev 2017-08-22 08:36:52 Re: proposal: psql command \graw
Previous Message Pavel Stehule 2017-08-22 07:32:06 proposal: psql command \graw