Hello Robert,
> I really, really wish you'd stop arguing against the patch to allow
> merging of pgbench logs in this basis.
Hmmm. I'm lost. I thought that discussing how to best implement a feature
was part of reviewing a patch.
> There may or may not be other reasons to reject that patch, but arguing
> that we can or should reject it because of the hypothetical possibility
> that sharing a file handle will work out just isn't right.
I must say that I do not understand why discussing options, and actually
implementing and testing them for hours to see the performance impact, is
bad, but it will save time next time.
As for pgbench thread forlk emulation induced complexity, I already paid
for some stuff I contributed to pgbench, so I feel I'm entitled to rant
about it:-)
> People who work hard to develop a patch
I know. I also spent quite some time on testing alternate implementations
on this one.
> that does something useful don't deserve to have it kicked to the curb
> because someone can imagine a development path that would eventually
> obsolete it. That patch deserves to be evaluated on its own merits.
Sure. I did that in the first post. The code is heavy and awkward, include
copy-pastes, the merge sorts (there are 2 of thems) complexity are bad,
the different log formats are hard coded and must be updated in several
place if modified or extended, ...
IMO this would be best outside of pgbench in a script, but this means that
the script must be given indication about the file format which depends on
the options used to run pgbench, which makes it awkward as well.
So the current status is between "rejected" and "returned with feedback",
make your pick.
Now I think that the feature provides value and I am trying to help
salvage it. I can do other things.
--
Fabien.
