Re: add modulo (%) operator to pgbench - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: add modulo (%) operator to pgbench
Date
Msg-id alpine.DEB.2.10.1409100917250.30320@sto
Whole thread Raw
In response to Re: add modulo (%) operator to pgbench  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: add modulo (%) operator to pgbench
List 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
trivialpatch, 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.



pgsql-hackers by date:

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