Re: add modulo (%) operator to pgbench

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: add modulo (%) operator to pgbench
Date: 2014-09-10 08:48:07
Message-ID: alpine.DEB.2.10.1409100917250.30320@sto
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hello Robert,

> 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.
> [...]

Probably.

To be clear about my intent, which is a summary of what you already know:
I would like to be able to generate a reasonable non uniform throttled
workload with pgbench.

I do think such a feature is worth having for anybody who would like to do
something realistic with pgbench, and that it is in the "general
interest" of postgresql to have such features.

In particular, given the current state of abysmal performance under some
trivial load with pg, I really think that it is really worth having a
better tool, and I think that my effort with rate and progress helped to
put these hidden problems into the light, and I do hope that they are
going to be solved quickly.

Now if I submitted a big patch with all the necessary features in it,
someone would ask to break it into pieces. So they are submitted one by
one (progress, throttling, limit, modulo, ...).

Note I did not start with the non uniform stuff, but Mitsumasa-san sent a
gaussian distribution patch and I jumped onto the wagon to complement it
with an exponential distribution patch. I knew when doing it that is was
not enough, but as I said "one piece at a time", given the effort required
to pass simple patch.

What is still needed for the overall purpose is the ability to scatter the
distribution. This is really:

(1) a positive remainder modulo, which is the trivial patch under
discussion

(2) a fast but good quality for the purpose hash function
also a rather small patch, not submitted yet.

(3) maybe the '|' operator to do a TP*-like non-uniform load,
which is really periodic so I do not like it.
a trivial patch, not submitted yet.

If you do not want one of these pieces (1 & 2), basically the interest of
gaussian/exponential addition is much reduced, and this is just a half
baked effort aborted because you did not want what was required to make it
useful. Well, I can only disagree, but you are a committer and I'm not!

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2014-09-10 08:54:19 Re: [TODO] Process pg_hba.conf keywords as case-insensitive
Previous Message Etsuro Fujita 2014-09-10 08:35:11 Re: PENDING_LIST_CLEANUP_SIZE - maximum size of GIN pending list Re: HEAD seems to generate larger WAL regarding GIN index