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-27 08:12:42
Message-ID: alpine.DEB.2.20.1708271008550.18068@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hello Masahiko-san,

> Attached latest v4 patch. Please review it.

Patch applies, compiles.

The messages/options do not seem to work properly:

sh> ./pgbench -i -I t
done.

Does not seem to have initialized the tables although it was requested...

sh> ./pgbench -i -I d
creating tables...
100000 of 100000 tuples (100%) done (elapsed 0.08 s, remaining 0.00 s)
done.

It seems that "d" triggered table creation... In fact it seems that the
work is done correctly, but the messages are not in the right place.

Also another issue:

sh> ./pgbench -i --foreign-keys
creating tables...
100000 of 100000 tuples (100%) done (elapsed 0.09 s, remaining 0.00 s)
vacuum...
set primary keys...
done.

Foreign keys do not seem to have been set... Please check that all really
work as expected.

About the documentation:

If a native English speaker could review the text, it would be great.

At least: "Required to invoke" -> "Require to invoke".

About the code:

is_no_vacuum should be a bool?

I'm really hesitating about the out of order processing of options. If the user writes

sh> pgbench -i --no-vacuum -I v
done.

Then does it make sense to ignore the last thing the user asked for? ISTM
that processing options in order and keeping the last resulting spec is
more natural. Appending contradictory options can happen easily when
scripting, and usual what is meant is the last one.

Again, as pointed out in the previous review, I do not like much
checkCustomCmds implementation: switch/case, fprintf and return on error
which will trigger another fprintf and error above... ISTM that you should
either take into account previous comments or explain why you disagree
with them, but not send the same code without addressing them in any way.

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2017-08-27 08:20:00 Re: pgbench: Skipping the creating primary keys after initialization
Previous Message Pavel Stehule 2017-08-27 07:52:28 Re: type cache for concat functions