Re: extend pgbench expressions with functions

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: extend pgbench expressions with functions
Date: 2016-02-16 08:03:48
Message-ID: CA+TgmoYBgtC0u6+6NNHE87G3LY89XRDDjEmbhpmFkfS=TiTfog@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Feb 16, 2016 at 1:55 AM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Tue, Feb 16, 2016 at 9:18 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> I experimented with trying to do this and ran into a problem: where
>> exactly would you store the evaluated arguments when you don't know
>> how many of them there will be? And even if you did know how many of
>> them there will be, wouldn't that mean that evalFunc or evaluateExpr
>> would have to palloc a buffer of the correct size for each invocation?
>> That's far more heavyweight than the current implementation, and
>> minimizing CPU usage inside pgbench is a concern. It would be
>> interesting to do some pgbench runs with this patch, or the final
>> patch, and see what effect it has on the TPS numbers, if any, and I
>> think we should. But the first concern is to minimize any negative
>> impact, so let's talk about how to do that.
>
> Good point. One simple idea here would be to use a custom pgbench
> script that has no SQL commands and just calculates the values of some
> parameters to measure the impact without depending on the backend,
> with a fixed number of transactions.

Sure, we could do that. But whether it materially changes pgbench -S
results, say, is a lot more important.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-02-16 08:05:47 Re: Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl
Previous Message Andres Freund 2016-02-16 07:59:43 Re: Remove or weaken hints about "effective resolution of sleep delays is 10 ms"?