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.