From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: extend pgbench expressions with functions |
Date: | 2016-01-12 12:44:42 |
Message-ID: | CAB7nPqQbXn+87jb_c7aDPj1RpLGQH=B_XYGC_5yWyNDGKqjmdw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jan 12, 2016 at 5:52 PM, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:
>> 2) When precising a value between 0 and 2, pgbench will loop
>> infinitely. For example:
>> \set cid debug(random_gaussian(-100, 100, 0))
>> In both cases we just lack sanity checks with PGBENCH_RANDOM,
>> PGBENCH_RANDOM_EXPONENTIAL and PGBENCH_RANDOM_GAUSSIAN. I think that
>> those checks would be better if moved into getExponentialRand & co
>> with the assertions removed. I would personally have those functions
>> return a boolean status and have the result in a pointer as a function
>> argument.
>
>
> ISTM that if pgbench is to be stopped, the simplest option is just to abort
> with a nicer error message from the get*Rand function, there is no need to
> change the function signature and transfer the error management upwards.
That's fine to me, as long as the solution is elegant.
>> I am attaching a patch where I tweaked a bit the docs and added some
>> comments for clarity. Patch is switched to "waiting on author" for the
>> time being.
>
> Ok. I'm hesitating about removing the operator management, especially if I'm
> told to put it back afterwards.
I can understand that, things like that happen all the time here and
that's not a straight-forward patch that we have here. I am sure that
additional opinions here would be good to have before taking one
decision or another. With the current statu-quo, let's just do what
you think is best.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2016-01-12 12:49:38 | Re: Speedup twophase transactions |
Previous Message | Andres Freund | 2016-01-12 12:42:53 | Allow to specify (auto-)vacuum cost limits relative to the database/cluster size? |