Re: add modulo (%) operator to pgbench

On Tue, Sep 9, 2014 at 11:07 AM, Fabien COELHO <coelho@cri.ensmp.fr> wrote:
>> The fact that you're agonizing about which modulo to add is a sign that
>> the language is too impoverished to let you do anything non-trivial.
>
> I'm not agonizing about which modulo to use:-) I know I do not want the
> C/SQL version which is never really useful if you have signed data. I
> overlooked this detail when submitting the first patch, and produced a
> stupid patch with all 3 possible modulos, before going to the sane solution
> which is to use the floored division Knuth version. If I had thought a bit,
> I would have sent v3 as v1 directly.

Sure, and I would have looked at that patch and complained that you
were implementing a modulo operator with different semantics than C.
And then we'd be right back where we are now.

The problem here isn't that I don't know what you want, or that what
you want is unreasonable.  The problem is that we can't cater to every
slightly-different thing that somebody wants to do with pgbench.  If
we try, we'll end up with a neverending jumble of features most of
which never get used by 1 or 2 people.  Features for any part of
PostgreSQL need to be of reasonably general interest, not something
that is super-specialized to one particular set of needs.  If I commit
what you're asking me to commit here, I think that's exactly what I'll
be doing, and I don't think that's a good idea.

In all seriousness, sometimes the right solution to these problems is
just to patch your own copy.  I've done that with pgbench at least
once and with PostgreSQL in general more times than I can conveniently
count.  I've learned a lot of useful things that way, but I can't
expect all of the debugging instrumentation and trial features that
I've created to get incorporated into the product.  It's not
reasonable, and it's not worth the time it would take me to make the
code general and maintainable, so the code just gets dropped on the
floor.  In a perfect world, that wouldn't happen, but in a perfect
world they'd pay me the same salary they pay Linus Torvalds.

In this particular instance, we got onto this topic in the first place
because of the Gaussian and exponential patches, and the desire to
have the "hot" portion of the keys distributed in some random way
through the data set rather than having everything be clustered at the
front.  As you yourself said, the best case for this patch is to allow
a poor-man's approximation of that.  Adding a weird non-standard
operator for a poor approximation of the feature we're really looking
for just doesn't feel like the right call.  I recognize that you have
a different view, and if enough people agree with you, that argument
may win the day.  But my opinion is that we are too far down in the
weeds.  We should be trying to create features that will have general
appeal to pgbench users, not features that solve narrow problems for
individual developers.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company