On Tue, Aug 15, 2017 at 2:43 AM, Fabien COELHO <coe...@cri.ensmp.fr> wrote: > > 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.
Agreed. > >>> 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". > Yeah, once custom initialization patch get committed we can extend it. Attached updated patch. I've incorporated the all comments from Fabien to it, and changed it to single letter version. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
pgbench_custom_initialization_v3.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
