|From:||Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>|
|To:||Stephen Frost <sfrost(at)snowman(dot)net>|
|Cc:||Jeevan Ladhe <jeevan(dot)ladhe(at)enterprisedb(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: pgbench more operators & functions|
|Views:||Raw Message | Whole Thread | Download mbox|
> I'm pretty sure we should hold off on adding 'xor' [...]
So I removed "xor" in the attached version.
>>> [...] I certainly understand how the if() function could be useful
>> Indeed, some kind of "if" is needed, for instance to implement
>> "tpc-b" correctly.
> That's an interesting point.. Have you thought about ripping out the
> built-in TPC-B-like functionality of pgbench and making that into a
> script instead? Doing so would likely point out places where we need to
> add functionality or cases which aren't handled very well. [...]
My point is not that pgbench should do tcp-b-real by default, but that it
should be possible to do it, and currently this is not possible. People
rely on what pgbench is doing so it should not be (significantly) changed,
at least in its default behavior.
> I'm not quite sure that I follow why you feel that CASE would be too
> difficult to implement here..?
Obviously, everything is possible, it just takes more time. I've added the
generic case expression syntax in the attached version.
> [...] If we're going to replace the built-in TPC-B functionality
As stated above, I do *NOT* want to replace the existing functionality, I
just want to make pgbench able to do more in a sensible & useful way for
I'm not currently planing to add user functions and control structures
outside of expressions in pgbench without a very strong user case.
> [...] Perhaps it'd be difficult to rework pgbench to support it, but I
> do think it's something we should at least be considering and making
> sure we don't wall ourselves off from implementing in the future. Most
> scripting languages do support functions of one form or another.
>>> Lastly, we should really add some regression tests to pgbench. We
>>> already have the start of a TAP test script which it looks like it
>>> wouldn't be too hard to add on to.
>> I agree that pgbench should be tested systematically. I think that
>> this is not limited to these functions and operators but a more
>> general and desirable feature, thus is really material for another
> I don't agree with this- at a minimum, this patch should add regression
> tests for the features that it's adding.
This has not been the case with the previous dozens of patches about
pgbench, but maybe it should start somewhere:-).
There was already one TAP script for pgbench (for testing concurrent oid
insertion, not really a pgbench functionnality), I added another one which
focusses on expressions.
Changes in v6:
- remove xor operator
- remove if function
- make keywords case insensitive (more like SQL)
- add generic case expression syntax
(note that the typing is the same strange one as pg, i.e.
CASE WHEN (RANDOM() > 0.5) THEN 1 ELSE 1.0 END;
can be either an int or a double, depending, this is not statically typed...
- add TAP test about pgbench expressions
|Next Message||Tom Lane||2016-10-04 16:57:34||Re: Misidentification of Python shared library|
|Previous Message||Robert Haas||2016-10-04 16:15:21||Re: pgbench more operators & functions|