Re: add modulo (%) operator to pgbench

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: add modulo (%) operator to pgbench
Дата
Msg-id alpine.DEB.2.10.1409100917250.30320@sto
обсуждение исходный текст
Ответ на Re: add modulo (%) operator to pgbench  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: add modulo (%) operator to pgbench  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Etsuro Fujita
Дата:
Сообщение: Re: PENDING_LIST_CLEANUP_SIZE - maximum size of GIN pending list Re: HEAD seems to generate larger WAL regarding GIN index
Следующее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: [TODO] Process pg_hba.conf keywords as case-insensitive