Re: pgbench more operators & functions - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: pgbench more operators & functions
Date
Msg-id alpine.DEB.2.20.1610040826120.7381@lancre
Whole thread Raw
In response to Re: pgbench more operators & functions  (Stephen Frost <sfrost@snowman.net>)
Responses Re: [HACKERS] pgbench more operators & functions  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
Hello Stephen,

> 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
benchmarking.

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.

Sure.

>>> 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
>> patch.
>
> 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

--
Fabien.
Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pgbench more operators & functions
Next
From: Tom Lane
Date:
Subject: Re: Misidentification of Python shared library