My justification for adding pl/pgsql tests as part of the immediately
available tests is that pl/pgsql itself is always enabled, so having a
no-effort way to test its performance benefits would be really helpful.
We also should have "tps-b-like as SQL function" to round up the "test
what's
On Tue, Aug 15, 2023 at 11:41 AM Nathan Bossart
wrote:
> Why's that? I'm not aware of any project policy that prohibits such
> enhancements to pgbench. It might take some effort to gather consensus on
> a proposal like this, but IMHO that doesn't mean we shouldn't try. If the
> prevailing
Thanks for the update.
I will give it another go over the weekend
Cheers,
Hannu
On Thu, Feb 1, 2024 at 7:33 PM vignesh C wrote:
> On Fri, 18 Aug 2023 at 23:04, Hannu Krosing wrote:
> >
> > I will address the comments here over this coming weekend.
>
> The patch which you submitted has been
On Fri, 18 Aug 2023 at 23:04, Hannu Krosing wrote:
>
> I will address the comments here over this coming weekend.
The patch which you submitted has been awaiting your attention for
quite some time now. As such, we have moved it to "Returned with
Feedback" and removed it from the reviewing
I will address the comments here over this coming weekend.
I think that in addition to current "tpc-b like" test we could also
have more modern "tpc-c like" and "tpc-h like" tests
And why not any other "* -like" from the rest of TPC-*, YCSP, sysbench, ... :)
though maybe not as part of
Hello Nathan,
I'm unclear about what variety of scripts that could be provided given the
tables made available with pgbench. ISTM that other scenari would involve
both an initialization and associated scripts, and any proposal would be
bared because it would open the door to anything.
Why's
On Tue, Aug 15, 2023 at 09:46:59AM +0200, Fabien COELHO wrote:
> I'm unclear about what variety of scripts that could be provided given the
> tables made available with pgbench. ISTM that other scenari would involve
> both an initialization and associated scripts, and any proposal would be
> bared
Hello Nathan,
1. so I don't have to create the script and function manually each
time I want to test mainly the database (instead of the
client-database system)
2. so that new users of PostgreSQL can easily see how much better OLTP
workloads perform when packaged up as a server-side function
On Wed, Jan 04, 2023 at 07:06:44PM +0100, Hannu Krosing wrote:
> 1. so I don't have to create the script and function manually each
> time I want to test mainly the database (instead of the
> client-database system)
>
> 2. so that new users of PostgreSQL can easily see how much better OLTP
>
On Fri, 24 Mar 2023 22:17:33 +
Cary Huang wrote:
> The following review has been posted through the commitfest application:
> make installcheck-world: not tested
> Implements feature: tested, passed
> Spec compliant: not tested
> Documentation:not tested
The
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
Hi
thank you for the patch. It can be applied to current master branch
Hello,
The attached patch adds pl/pgsql versions of "tpcb-like" and
"simple-update" internal test scripts
Why not, it makes sense because it is relevant to some usage patterns.
Why not having the select version as a version as well?
If we are going to follow this road, we could also
Hello Hackers,
The attached patch adds pl/pgsql versions of "tpcb-like" and
"simple-update" internal test scripts
The tests perform functionally exactly the same, but are generally
faster as they avoid most client-server latency.
The reason I'd like to have them as part of pgbench are two
1.
13 matches
Mail list logo
