Re: pgbench more operators & functions

From: Fabien COELHO <fabien(dot)coelho(at)mines-paristech(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Jeevan Ladhe <jeevan(dot)ladhe(at)enterprisedb(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgbench more operators & functions
Date: 2017-01-25 07:19:20
Message-ID: alpine.DEB.2.20.1701250652500.29470@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Hello Tom,

> I concur that this is expanding pgbench's expression language well beyond
> what anybody has shown a need for.

As for the motivation, I'm assuming that pgbench should provide features
necessary to implement benchmarks, so I'm adding operators that appear in
standard benchmark specifications.

From TPC-B 2.0.0 section 5.3.5:

| The Account_ID is generated as follows:
| • A random number X is generated within [0,1]
| • If X<0.85 or branches = 1, a random Account_ID is selected over all
| <Branch_ID> accounts.
| • If X>=0.85 and branches > 1, a random Account_ID is selected over all
| non-<Branch_ID> accounts.

The above uses a condition (If), logic (or, and), comparisons (=, <, >=).

From TPC-C 5.11 section 2.1.6, a bitwise-or operator is used to skew a

| NURand (A, x, y) = (((random (0, A) | random (x, y)) + C) % (y - x + 1)) + x

And from section of same, some time is computed based on a

| Tt = -log(r) * µ

> I'm also concerned that there's an opportunity cost here, in that the
> patch establishes a precedence ordering for its new operators, which
> we'd have a hard time changing later. That's significant because the
> proposed precedence is different from what you'd get for similarly-named
> operators on the backend side. I realize that it's trying to follow the
> C standard instead,

Oops. I just looked at the precedence from a C parser, without realizing
that precedence there was different from postgres SQL implementation:-(
This is a bug on my part.

> I'd be okay with the parts of this that duplicate existing backend syntax
> and semantics, but I don't especially want to invent further than that.

Okay. In the two latest versions sent, discrepancies from that were bugs,
I was trying to conform.

Version 8 attached hopefully fixes the precedence issue raised above:

- use precedence taken from "backend/gram.y" instead of C. I'm not sure
that it is wise that pg has C-like operators with a different
precedence, but this is probably much too late...

And fixes the documentation:

- remove a non existing anymore "if" function documentation which made
Robert assume that I had not taken the hint to remove it. I had!

- reorder operator documentation by their pg SQL precedence.


Attachment Content-Type Size
pgbench-more-ops-funcs-8.patch text/x-diff 21.8 KB
functions.sql application/x-sql 1.0 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2017-01-25 07:22:52 Re: pgbench more operators & functions
Previous Message Andrew Borodin 2017-01-25 07:09:37 Re: Review: GIN non-intrusive vacuum of posting tree