Re: [HACKERS] pgbench more operators & functions
От | Fabien COELHO |
---|---|
Тема | Re: [HACKERS] pgbench more operators & functions |
Дата | |
Msg-id | alpine.DEB.2.20.1701250935560.29470@lancre обсуждение исходный текст |
Список | pgsql-hackers |
<Oops, resent, wrong from again, I must really do something about my 1000 mail addresses> 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 distribution: | NURand (A, x, y) = (((random (0, A) | random (x, y)) + C) % (y - x + 1)) + x And from section 5.2.5.4 of same, some time is computed based on a logarithm: | 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. -- Fabien. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
В списке pgsql-hackers по дате отправления: