Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" testpending solution of its timing is (fwd)
От | Fabien COELHO |
---|---|
Тема | Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" testpending solution of its timing is (fwd) |
Дата | |
Msg-id | alpine.DEB.2.21.1905231615480.28482@lancre обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" testpending solution of its timing is (fwd) (Fabien COELHO <coelho@cri.ensmp.fr>) |
Ответы |
Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" testpending solution of its timing is (fwd)
|
Список | pgsql-hackers |
V11 is just a rebase after the reindentation patches. > Indeed, yet again, I forgot the attachement:-( > >>> I stared at the new test case for a while, and I must say it looks very >>> cryptic. It's not exactly this patch's fault - all the pgbench tests are >>> cryptic - >> >> Perl is cryptic. Regexprs are cryptic. >> >>> but I think we need to do something about that before adding any more >>> tests. I'm not sure what exactly, but I'd like them to be more like >>> pg_regress tests, where you have an expected output and you compare it >>> with the actual output. I realize that's not easy, because there are a lot >>> of varying numbers in the output, but we've got to do something. >>> >>> As a good first step, I wish the pgbench() function used named arguments. >>> [...] >>> >>> You would have something like this: >>> >>> my $elapsed = pgbench( >>> test_name => 'pgbench progress', >>> opts => '-T 2 -P 1 -l --aggregate-interval=1' >> >> I do not like them much in perl because it changes the code significantly, >> but why not. That would be another patch anyway. >> >> A lighter but efficient option would be to add a few comments on the larger >> calls, see attached. > > Please really find the attachement, and do not hesitate to share spare a few > grey cells so that I will not forget about them in the futur:-) > > -- Fabien.
Вложения
В списке pgsql-hackers по дате отправления: