Re: pgbench - allow to create partitioned tables

Hello Amit,

>>    sh> pgbench -T 10
>>    ...
>>    partitions: 0
>
> I am not sure how many users would be able to make out that it is a
> run where actual partitions are not present unless they beforehand
> know and detect such a condition in their scripts.

> What is the use of such a run which completes without actual updates?

Why should we decide that they cannot do that?

The user could be testing the overhead of no-op updates, which is 
something interesting, and check what happens with partitioning in this 
case. For that, they may delete pgbench_accounts contents or its 
partitions for partitioned version, or only some partitions, or whatever.

A valid (future) case is that hopefully dynamic partitioning could be 
implemented, thus no partitions would be a perfectly legal state even with 
the standard benchmarking practice. Maybe the user just wrote a clever 
extension to do that with a trigger and wants to test the performance 
overhead with pgbench. Fine!

IMHO we should not babysit the user by preventing them to run a bench 
which would not generate any error, so is fundamentaly legal. If running a 
bench should fail, it should fail while running it, not before even 
starting. I have already added at your request early failures modes to the 
patch about which I'm not very happy.

Note that I'm mostly okay with warnings, but I know that I do not know 
what use may be done with pgbench, and I do not want to decide for users.

In this case, franckly I would not bother to issue a warning which has a 
very low probability ever to be raised.

> I think it is better if give an error for such a case rather than 
> allowing to execute it and then give some information which doesn't make 
> much sense.

I strongly disagree, as explained above.

>> I incorporated most of them, although I made them terser, and fixed them
>> when inaccurate.
>>
>> I did not buy moving the condition inside the fillfactor function.
>
> I also don't agree with your position.  My main concern here is that
> we can't implicitly assume that fillfactor need to be appended.

Sure.

> At the very least we should have a comment saying why we are always 
> appending the fillfactor for partitions

The patch does not do that, the condition is just before the call, not 
inside it with a boolean passed as an argument. AFAICS the behavior of v14 
is exactly the same as your version and as the initial code.

-- 
Fabien.