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-14 17:43:47 |
Message-ID: | alpine.DEB.2.20.1708141901470.21878@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello,
> I think we can use it like --custom-initialize="create_table, vacuum"
> which is similar to what we specify a connection option to psql for
> example.
Even if it is allowed, do not advertise it. Or use space as a separator
and not comma. ISTM that with psql connections space is the higher level
separator, not an optional thing, and comma is used for lower level
splitting: "host=foo port=5432,5433 ..."
> But it will be unnecessary if we have the one letter version.
Sure.
>> I'm also wondering whether using a list is a good option, because it implies
>> a large parse function, list management and so on. With the one letter
>> version, it could be just a string to be scanned char by char for
>> operations.
>
> I basically agree with the one letter version. But I'm concerned that
> it'll confuse users if we have more initialization steps for the
> pgbench initialization. If we add more various initialization steps it
> makes pgbench command hard to read and the users might have to
> remember these options.
I think that if we get to the point where so many initialization steps
that people get confused, then adding long names will not be an issue:-)
In the mean time it only needs 5 values.
>> Maybe there could be short-hands for usual setups, eg "default" for "tdpv"
>> or maybe "ct,ld,pk,va", "full" for "tdpfv" or maybe "ct,ld,pk,fk,va"...
>
> If --custom-initialize option requires for i option to be set,
> "pgbench -i" means the initialization with full steps and "pgbench -i
> --custom-initialize=..." means the initialization with custom
> operation steps.
Sure. It does not preclude the default to have a name.
>> Remove the "no-primary-keys" from the long option array as it has
>> disappeared. You might consider make "custom-initialize" take the 'I' short
>> option.
>>
>> Ranting unrelated to this patch: the automatic aid type switching based on
>> scale is a bad idea (tm), because when trying to benchmark it means that
>> changing the scale also changes the schema, and you really do not need that.
>> ISTM that it should always use INT8.
>
> Hmm, I think it's a valid point. Should we allow users to specify like
> the above thing in the custom initialization feature as well?
I would be in favor of having an option to do a tpc-b conforming schema
which would include that, but which would also change the default balance
type which is not large enough per spec. Maybe it could be "T".
--
Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2017-08-14 17:53:46 | Re: Fix a typo in sequence.c |
Previous Message | Peter Geoghegan | 2017-08-14 17:41:24 | Re: Crash report for some ICU-52 (debian8) COLLATE and work_mem values |