From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: extend pgbench expressions with functions |
Date: | 2015-07-23 13:50:16 |
Message-ID: | alpine.DEB.2.10.1507231540470.9309@sto |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello Heikki,
>> This patch extends pgbench expression with functions. Currently only one
>> "abs" function is added. The point is rather to bootstrap the
>> infrastructure for other functions (such as hash, random variants...) to
>> be added later.
>
> I think it would actually be good to add at least some of those other
> functions in the initial patch.
Hmmm, sure. I wanted some feedback on the "how" before doing that, hence
the infrastructure patch submitted with just one fonction. Obviously I can
expand, but before that any opinion on the "how"?
For instance I decided against having individual functions recognized by
the lexer, and to really have an infrastructure for storing, checking and
adding them without lex/yacc.
> The infrastructure that this patch adds only supports arguments with a
> single argument, so it won't get us very far.
> Also, will we need non-integer (e.g. string, numeric, whatever)
> arguments for the functions?
Maybe float *constants* for random exponential & gaussian.
> How about other datatypes for variables in general?
The point is not to develop another full language in pgbench. People can
do things with PL/pgSQL & server side if it must be really advanced, the
point is really to facilitate pgbench "simple" scripts.
> Perhaps not, or if we do that can be a separate patch, but it's
> something to keep in mind. The pgbench script language is evolving into
> a full-blown Turing-complete programming language...
The point is *NOT* to do that. For Turing, basically you would need while
or recursion & condition. Currently there is no such thing and not plan
for such thing, and I do not think it is desirable.
> As an initial list of functions, I'd suggest:
>
> abs(x)
This is the one included in the patch.
> min(x, y, ...)
> max(x, y, ...)
Hmm, varargs...
> random_uniform(min, max)
Ok. probably just "random"?
> random_gaussian(min, max, threshold)
> random_exponential(min, max, threshold)
Hmm, threshold is a float.
> As soon as we add more functions, the way they are documented needs to
> be reworked too; we'll need to add a table in the manual to list them.
Yep.
--
Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-07-23 14:01:07 | Re: TABLESAMPLE patch is really in pretty sad shape |
Previous Message | Laurent Laborde | 2015-07-23 13:10:50 | Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ] |