| From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
|---|---|
| To: | David Christensen <david(dot)christensen(at)crunchydata(dot)com> |
| Cc: | "Imseih (AWS), Sami" <simseih(at)amazon(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [PATCH] pgbench: add multiconnect option |
| Date: | 2022-03-25 09:50:09 |
| Message-ID: | alpine.DEB.2.22.394.2203250939510.3449922@pseudo |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>>> Pgbench is a simple benchmark tool by design, and I wonder if adding
>>> a multiconnect feature will cause pgbench to be used incorrectly.
>>
>> Maybe, but I do not see how it would be worse that what pgbench already
>> allows.
>>
>
> I agree that pgbench is simple; perhaps really too simple when it comes to
> being able to measure much more than basic query flows. What pgbench does
> have in its favor is being distributed with the core distribution.
>
> I think there is definitely space for a more complicated benchmarking tool
> that exercises more scenarios and more realistic query patterns and
> scenarios. Whether that is distributed with the core is another question.
As far as this feature is concerned, the source code impact of the patch
is very small, so I do not think that is worth barring this feature on
that ground.
--
Fabien.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ashutosh Bapat | 2022-03-25 09:55:42 | Re: identifying unrecognized node type errors |
| Previous Message | Alvaro Herrera | 2022-03-25 09:42:14 | Re: turn fastgetattr and heap_getattr to inline functions |