>> I'm not sure about the implication of ALTER on the table storage,
>
> Should be fine in this case. But if that's what you're concerned about -
> understandably -
Indeed, my (long) experience with benchmarks is that it is a much more
complicated that it looks if you want to really understand what you are
getting, and to get anything meaningful.
> it seems to make more sense to split -i into two. One to create the
> tables, and another to fill them. That'd allow to do manual stuff
> inbetween.
Hmmm. This would mean much more changes than the pretty trivial patch I
submitted: more options (2 parts init + compatibility with the previous
case), splitting the "init" function, having a dependency and new error
cases to check (you must have the table to fill them), some options apply
to first part while other apply to second part, which would lead in any
case to a signicantly more complicated documentation... a lot of trouble
for my use case to answer Josh pertinent comments, and to be able to test
the "tuple size" factor easily. Moreover, I would reject it myself as too
much trouble for a small benefit.
Feel free to reject the patch if you do not want it. I think that its
cost/benefit is reasonable (one small option, small code changes, some
benefit for people who want to measure performance in various cases).
--
Fabien.
