Re: [HACKERS] add modulo (%) operator to pgbench

2015-03-04 Thread Fabien COELHO
On Mon, Mar 2, 2015 at 5:41 PM, Fabien COELHO coe...@cri.ensmp.fr wrote: but I'd like to have a more robust discussion about what we want the error reporting to look like rather than just sliding it into this patch. As an input, I suggest that the error reporting feature should provide a

Re: [HACKERS] add modulo (%) operator to pgbench

2015-03-03 Thread Robert Haas
On Mon, Mar 2, 2015 at 5:41 PM, Fabien COELHO coe...@cri.ensmp.fr wrote: but I'd like to have a more robust discussion about what we want the error reporting to look like rather than just sliding it into this patch. As an input, I suggest that the error reporting feature should provide a clue

Re: [HACKERS] add modulo (%) operator to pgbench

2015-03-02 Thread Robert Haas
On Sun, Mar 1, 2015 at 1:42 PM, Robert Haas robertmh...@gmail.com wrote: On Sat, Feb 28, 2015 at 12:06 PM, Stephen Frost sfr...@snowman.net wrote: I took a look through the patch and the discussion and it certainly seems ready to me. I agree with Robert- let's go ahead and get this in and

Re: [HACKERS] add modulo (%) operator to pgbench

2015-03-01 Thread Robert Haas
On Sat, Feb 28, 2015 at 12:06 PM, Stephen Frost sfr...@snowman.net wrote: I took a look through the patch and the discussion and it certainly seems ready to me. I agree with Robert- let's go ahead and get this in and then folks can build on top of it. I'm guessing it was added as Needs

Re: [HACKERS] add modulo (%) operator to pgbench

2015-02-28 Thread Stephen Frost
* Fabien COELHO (coe...@cri.ensmp.fr) wrote: On Mon, Jan 5, 2015 at 10:37 AM, Fabien COELHO coe...@cri.ensmp.fr wrote: Anyway, I suggest to keep that for another round and keep the Robert's isofunctional patch as it is before extending. +1. Let's please get the basic thing committed, and

Re: [HACKERS] add modulo (%) operator to pgbench

2015-02-25 Thread Fabien COELHO
On Mon, Jan 5, 2015 at 10:37 AM, Fabien COELHO coe...@cri.ensmp.fr wrote: Anyway, I suggest to keep that for another round and keep the Robert's isofunctional patch as it is before extending. +1. Let's please get the basic thing committed, and then people can write more patches to extend

Re: [HACKERS] add modulo (%) operator to pgbench

2015-01-05 Thread Fabien COELHO
I'm also just looking at you ERROR() macro, it seems that core code is quite careful not to use __VA_ARGS__ on compilers where HAVE__VA_ARGS is not defined. I'd say this needs to be fixed too. Have a look at the trick used in elog.h for when HAVE__VA_ARGS is not defined. Here is a v5 with

Re: [HACKERS] add modulo (%) operator to pgbench

2015-01-05 Thread David Rowley
On 1 January 2015 at 21:23, Fabien COELHO coe...@cri.ensmp.fr wrote: I was about to go and look at this, but I had a problem when attempting to compile with MSVC. Thanks! Here is a v4 which includes your fix. I'm also just looking at you ERROR() macro, it seems that core code is quite

Re: [HACKERS] add modulo (%) operator to pgbench

2015-01-05 Thread Fabien COELHO
I'm also just looking at you ERROR() macro, it seems that core code is quite careful not to use __VA_ARGS__ on compilers where HAVE__VA_ARGS is not defined. I'd say this needs to be fixed too. Have a look at the trick used in elog.h for when HAVE__VA_ARGS is not defined. Indeed. The

Re: [HACKERS] add modulo (%) operator to pgbench

2015-01-05 Thread Alvaro Herrera
David Rowley wrote: I'm also just looking at you ERROR() macro, it seems that core code is quite careful not to use __VA_ARGS__ on compilers where HAVE__VA_ARGS is not defined. I'd say this needs to be fixed too. Have a look at the trick used in elog.h for when HAVE__VA_ARGS is not defined.

Re: [HACKERS] add modulo (%) operator to pgbench

2015-01-05 Thread Alvaro Herrera
Fabien COELHO wrote: I'm also just looking at you ERROR() macro, it seems that core code is quite careful not to use __VA_ARGS__ on compilers where HAVE__VA_ARGS is not defined. I'd say this needs to be fixed too. Have a look at the trick used in elog.h for when HAVE__VA_ARGS is not

Re: [HACKERS] add modulo (%) operator to pgbench

2015-01-05 Thread Fabien COELHO
Hello Alvaro, Here is a v6 with most of your suggestions applied. On top of evaluateExpr() we need a comment (generally I think pgbench could do with more comments; not saying your patch should add them, just expressing an opinion.) Also, intuitively I would say that the return values of

Re: [HACKERS] add modulo (%) operator to pgbench

2015-01-05 Thread Fabien COELHO
Hello Alvaro, On top of evaluateExpr() we need a comment (generally I think pgbench could do with more comments; not saying your patch should add them, just expressing an opinion.) Having spent some time in pgbench, I agree that more comments are a good thing. Also, intuitively I would

Re: [HACKERS] add modulo (%) operator to pgbench

2015-01-05 Thread Fabien COELHO
I'm also just looking at you ERROR() macro, it seems that core code is quite careful not to use __VA_ARGS__ on compilers where HAVE__VA_ARGS is not defined. I'd say this needs to be fixed too. Have a look at the trick used in elog.h for when HAVE__VA_ARGS is not defined. Hm, I just looked at

Re: [HACKERS] add modulo (%) operator to pgbench

2015-01-01 Thread Fabien COELHO
I was about to go and look at this, but I had a problem when attempting to compile with MSVC. Thanks! Here is a v4 which includes your fix. -- Fabien.diff --git a/contrib/pgbench/.gitignore b/contrib/pgbench/.gitignore index 489a2d6..aae819e 100644 --- a/contrib/pgbench/.gitignore +++

Re: [HACKERS] add modulo (%) operator to pgbench

2015-01-01 Thread Fabien COELHO
Hello David, At the moment I feel the patch is a bit half done. I really think that since the gaussian and exponential stuff was added in commit ed802e7d, that this should now be changed so that we have functions like random(), erandom() and grandom() and the way to use this becomes: \set

Re: [HACKERS] add modulo (%) operator to pgbench

2015-01-01 Thread David Rowley
On 1 January 2015 at 21:23, Fabien COELHO coe...@cri.ensmp.fr wrote: I was about to go and look at this, but I had a problem when attempting to compile with MSVC. Thanks! Here is a v4 which includes your fix. Thank you. I've had a quick look at the patch as I'm quite interested in

Re: [HACKERS] add modulo (%) operator to pgbench

2015-01-01 Thread Alvaro Herrera
David Rowley wrote: At the moment I feel the patch is a bit half done. I really think that since the gaussian and exponential stuff was added in commit ed802e7d, that this should now be changed so that we have functions like random(), erandom() and grandom() and the way to use this becomes:

Re: [HACKERS] add modulo (%) operator to pgbench

2014-12-31 Thread Fabien COELHO
Here is a review updated version of the patch. Patch applies and compiles without problem on current head, and worked for the various tests I made with custom scripts. This patch is a good thing, and I recommand warmly its inclusion. It extends greatly pgbench custom capabilities by allowing

Re: [HACKERS] add modulo (%) operator to pgbench

2014-12-31 Thread Fabien COELHO
I'm not sure about what Makefile changes could be necessary for various environments, it looks ok to me as it is. Found one. EXTRA_CLEAN is needed for generated C files. Added to this v3. -- Fabien.diff --git a/contrib/pgbench/.gitignore b/contrib/pgbench/.gitignore index 489a2d6..aae819e

Re: [HACKERS] add modulo (%) operator to pgbench

2014-12-31 Thread David Rowley
On 1 January 2015 at 04:02, Fabien COELHO coe...@cri.ensmp.fr wrote: I'm not sure about what Makefile changes could be necessary for various environments, it looks ok to me as it is. Found one. EXTRA_CLEAN is needed for generated C files. Added to this v3. I was about to go and look at

Re: [HACKERS] add modulo (%) operator to pgbench

2014-12-13 Thread Andrew Dunstan
On 11/24/2014 07:26 AM, Heikki Linnakangas wrote: On 09/25/2014 05:10 AM, Robert Haas wrote: On Wed, Sep 24, 2014 at 2:34 PM, Fabien COELHO coe...@cri.ensmp.fr wrote: Sigh. How to transform a trivial 10 lines patch into a probably 500+ lines project involving flex bison some non trivial

Re: [HACKERS] add modulo (%) operator to pgbench

2014-12-13 Thread Fabien COELHO
As it doesn't have documentation, I'm inclined to say we should mark this as Waiting on Author or Returned with Feedback. I'm planing to have a detailed look at Robert's patch before the end of the year. I could update pgbench documentation while doing that. -- Fabien. -- Sent via

Re: [HACKERS] add modulo (%) operator to pgbench

2014-12-13 Thread Andrew Dunstan
On 12/13/2014 01:19 PM, Fabien COELHO wrote: As it doesn't have documentation, I'm inclined to say we should mark this as Waiting on Author or Returned with Feedback. I'm planing to have a detailed look at Robert's patch before the end of the year. I could update pgbench documentation

Re: [HACKERS] add modulo (%) operator to pgbench

2014-11-24 Thread Heikki Linnakangas
On 09/25/2014 05:10 AM, Robert Haas wrote: On Wed, Sep 24, 2014 at 2:34 PM, Fabien COELHO coe...@cri.ensmp.fr wrote: Sigh. How to transform a trivial 10 lines patch into a probably 500+ lines project involving flex bison some non trivial data structures, and which may get rejected on any

Re: [HACKERS] add modulo (%) operator to pgbench

2014-09-25 Thread Fabien COELHO
Hello Robert, I think you're making a mountain out of a molehill. Probably. I tend to try the minimum effort first. I implemented this today in about three hours. The patch is attached. Great! Your patch is 544 lines, my size evaluation was quite good:-) Note that I probably spent 10

Re: [HACKERS] add modulo (%) operator to pgbench

2014-09-25 Thread Fabien COELHO
I think you're making a mountain out of a molehill. I implemented this today in about three hours. I think you're greatly understating your own efficiency at shift/reducing parser mountains down to molehills. Fabien even guessed the LOC size of the resulting patch with less than a 9%

Re: [HACKERS] add modulo (%) operator to pgbench

2014-09-25 Thread Robert Haas
On Thu, Sep 25, 2014 at 1:27 AM, Gregory Smith gregsmithpg...@gmail.com wrote: On 9/24/14, 10:10 PM, Robert Haas wrote: I think you're making a mountain out of a molehill. I implemented this today in about three hours. I think you're greatly understating your own efficiency at shift/reducing

Re: [HACKERS] add modulo (%) operator to pgbench

2014-09-25 Thread Gregory Smith
On 9/25/14, 8:38 AM, Robert Haas wrote: That's my whole reason for not wanting to adopt Fabien's approach in the first place: I was cool with exposing C's modulo operator, but any other modulo semantics seem like they should be built up from general-purpose primitives. Maybe; I don't quite

Re: [HACKERS] add modulo (%) operator to pgbench

2014-09-24 Thread Fabien COELHO
Hello Heikki, If you reject it, you can also remove the gaussian and exponential random distribution which is near useless without a mean to add a minimal pseudo-random stage, for which (x * something) % size is a reasonable approximation, hence the modulo submission. I'm confused. The

Re: [HACKERS] add modulo (%) operator to pgbench

2014-09-24 Thread Heikki Linnakangas
On 09/24/2014 10:45 AM, Fabien COELHO wrote: Currently these distributions are achieved by mapping a continuous function onto integers, so that neighboring integers get neighboring number of draws, say with size=7: #draws 10 6 3 1 0 0 0 // some exponential distribution int drawn

Re: [HACKERS] add modulo (%) operator to pgbench

2014-09-24 Thread Kevin Grittner
Fabien COELHO coe...@cri.ensmp.fr wrote: So my opinion is that this small modulo operator patch is both useful and harmless, so it should be committed. You've really failed to make that case --- in particular, AFAICS there is not even consensus on the exact semantics that the operator should

Re: [HACKERS] add modulo (%) operator to pgbench

2014-09-24 Thread Tom Lane
Kevin Grittner kgri...@ymail.com writes: Assuming that all values are integers, for: x = a / b; y = a % b; If b is zero either statement must generate an error. If a and b have the same sign, x must be positive; else x must be negative. It must hold that abs(x) is equal to abs(a)

Re: [HACKERS] add modulo (%) operator to pgbench

2014-09-24 Thread Fabien COELHO
No, it depends totally on the application. For financial and physical inventory purposes where I have had occasion to use it, the properties which were important were: [...] Hmmm. Probably I'm biased towards my compiler with an integer linear flavor field, where C-like % is always a pain,

Re: [HACKERS] add modulo (%) operator to pgbench

2014-09-24 Thread Fabien COELHO
The idea of a modulo operator was not rejected, we'd just like to have the infrastructure in place first. Sigh. How to transform a trivial 10 lines patch into a probably 500+ lines project involving flex bison some non trivial data structures, and which may get rejected on any ground...

Re: [HACKERS] add modulo (%) operator to pgbench

2014-09-24 Thread Heikki Linnakangas
On 09/24/2014 09:34 PM, Fabien COELHO wrote: The idea of a modulo operator was not rejected, we'd just like to have the infrastructure in place first. Sigh. How to transform a trivial 10 lines patch into a probably 500+ lines project involving flex bison some non trivial data structures,

Re: [HACKERS] add modulo (%) operator to pgbench

2014-09-24 Thread Robert Haas
On Wed, Sep 24, 2014 at 2:34 PM, Fabien COELHO coe...@cri.ensmp.fr wrote: Sigh. How to transform a trivial 10 lines patch into a probably 500+ lines project involving flex bison some non trivial data structures, and which may get rejected on any ground... Maybe I'll set that as a student

Re: [HACKERS] add modulo (%) operator to pgbench

2014-09-24 Thread Gregory Smith
On 9/24/14, 10:10 PM, Robert Haas wrote: I think you're making a mountain out of a molehill. I implemented this today in about three hours. I think you're greatly understating your own efficiency at shift/reducing parser mountains down to molehills. Fabien even guessed the LOC size of the

Re: [HACKERS] add modulo (%) operator to pgbench

2014-09-23 Thread Fabien COELHO
Hello Stephen, But this is not convincing. Adding a unary function with a clean syntax indeed requires doing something with the parser. Based on the discussion so far, it sounds like you're coming around to agree with Robert (as I'm leaning towards also) that we'd be better off building a

Re: [HACKERS] add modulo (%) operator to pgbench

2014-09-23 Thread Tom Lane
Fabien COELHO coe...@cri.ensmp.fr writes: So my opinion is that this small modulo operator patch is both useful and harmless, so it should be committed. You've really failed to make that case --- in particular, AFAICS there is not even consensus on the exact semantics that the operator should

Re: [HACKERS] add modulo (%) operator to pgbench

2014-09-23 Thread Stephen Frost
* Tom Lane (t...@sss.pgh.pa.us) wrote: Fabien COELHO coe...@cri.ensmp.fr writes: So my opinion is that this small modulo operator patch is both useful and harmless, so it should be committed. You've really failed to make that case --- in particular, AFAICS there is not even consensus on

Re: [HACKERS] add modulo (%) operator to pgbench

2014-09-23 Thread Fabien COELHO
So my opinion is that this small modulo operator patch is both useful and harmless, so it should be committed. You've really failed to make that case --- in particular, AFAICS there is not even consensus on the exact semantics that the operator should have. There is. Basically whatever with

Re: [HACKERS] add modulo (%) operator to pgbench

2014-09-23 Thread Heikki Linnakangas
On 09/23/2014 09:15 PM, Fabien COELHO wrote: So I'm inclined to reject rather than put in something that may cause surprises down the road. The usefulness doesn't seem great enough to take that risk. Marked as Returned with feedback. If you reject it, you can also remove the gaussian and

Re: [HACKERS] add modulo (%) operator to pgbench

2014-09-22 Thread Stephen Frost
Fabien, * Fabien COELHO (coe...@cri.ensmp.fr) wrote: That's not really true. You can't really add abs(x) or hash(x) right now because the current code only supports this syntax: \set varname operand1 [ operator operand2 ] There's no way to add support for a unary operator with that

Re: [HACKERS] add modulo (%) operator to pgbench

2014-09-11 Thread Fabien COELHO
Hello Robert, I am not objecting to the functionality; I'm objecting to bolting on ad-hoc operators one at a time. I think an expression syntax would let us do this in a much more scalable way. If I had time, I'd go do that, but I don't. We could add abs(x) and hash(x) and it would all be

Re: [HACKERS] add modulo (%) operator to pgbench

2014-09-11 Thread Mitsumasa KONDO
2014-09-11 15:47 GMT+09:00 Fabien COELHO coe...@cri.ensmp.fr: Hello Robert, I am not objecting to the functionality; I'm objecting to bolting on ad-hoc operators one at a time. I think an expression syntax would let us do this in a much more scalable way. If I had time, I'd go do that,

Re: [HACKERS] add modulo (%) operator to pgbench

2014-09-11 Thread Robert Haas
On Thu, Sep 11, 2014 at 2:47 AM, Fabien COELHO coe...@cri.ensmp.fr wrote: Ok. I do agree that an expression syntax would be great! However, that would not diminish nor change much the amount and kind of code necessary to add an operator or a function That's not really true. You can't really

Re: [HACKERS] add modulo (%) operator to pgbench

2014-09-11 Thread Fabien COELHO
However, that would not diminish nor change much the amount and kind of code necessary to add an operator or a function That's not really true. You can't really add abs(x) or hash(x) right now because the current code only supports this syntax: \set varname operand1 [ operator operand2 ]

Re: [HACKERS] add modulo (%) operator to pgbench

2014-09-10 Thread Fabien COELHO
Hello Robert, Sure, and I would have looked at that patch and complained that you were implementing a modulo operator with different semantics than C. And then we'd be right back where we are now. [...] Probably. To be clear about my intent, which is a summary of what you already know: I

Re: [HACKERS] add modulo (%) operator to pgbench

2014-09-10 Thread Robert Haas
On Wed, Sep 10, 2014 at 4:48 AM, Fabien COELHO coe...@cri.ensmp.fr wrote: Note I did not start with the non uniform stuff, but Mitsumasa-san sent a gaussian distribution patch and I jumped onto the wagon to complement it with an exponential distribution patch. I knew when doing it that is was

Re: [HACKERS] add modulo (%) operator to pgbench

2014-09-09 Thread Robert Haas
On Wed, Aug 6, 2014 at 3:22 PM, Fabien COELHO coe...@cri.ensmp.fr wrote: Maybe we ought to break down and support a real expression syntax. Sounds like that would be better all around. Adding operators is more or less orthogonal with providing a new expression syntax. I'm not sure that there

Re: [HACKERS] add modulo (%) operator to pgbench

2014-09-09 Thread Fabien COELHO
Hello Robert, Writing a simple expression parser for pgbench using flex and bison would not be an inordinately difficult problem. Sure. Note that there is not only the parsing but also the evaluating to think of, which mean a data structure to represent the expressions which would be more

Re: [HACKERS] add modulo (%) operator to pgbench

2014-09-09 Thread Robert Haas
On Tue, Sep 9, 2014 at 11:07 AM, Fabien COELHO coe...@cri.ensmp.fr wrote: The fact that you're agonizing about which modulo to add is a sign that the language is too impoverished to let you do anything non-trivial. I'm not agonizing about which modulo to use:-) I know I do not want the C/SQL

Re: [HACKERS] add modulo (%) operator to pgbench

2014-09-08 Thread Mitsumasa KONDO
Hi, Here is the review result. #1. Patch compatibility Little bit hunk, but it can patch to latest master. #2. Functionality No problem. #3. Documentation I think modulo operator explanation should put at last at the doc line. Because the others are more frequently used. #4. Algorithm You

Re: [HACKERS] add modulo (%) operator to pgbench

2014-09-08 Thread Fabien COELHO
Hello Mutsumara-san, #3. Documentation I think modulo operator explanation should put at last at the doc line. Because the others are more frequently used. So I like patch3 which is simple and practical. Ok. If you agree or reply my comment, I will mark ready for commiter. Please find

Re: [HACKERS] add modulo (%) operator to pgbench

2014-09-08 Thread Mitsumasa KONDO
Hi Fabien-san, Thank you for your fast work! 2014-09-08 23:08 GMT+09:00 Fabien COELHO coe...@cri.ensmp.fr: Hello Mutsumara-san, #3. Documentation I think modulo operator explanation should put at last at the doc line. Because the others are more frequently used. So I like patch3

Re: [HACKERS] add modulo (%) operator to pgbench

2014-09-08 Thread Fabien COELHO
The attached is seemed no problem. But I'd like to say about order of explanation in five formulas. Fix version is here. Please confirm, and I mark it for ready for commiter. I'm ok with this version. -- Fabien. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

Re: [HACKERS] add modulo (%) operator to pgbench

2014-08-06 Thread Fabien COELHO
Hello Robert, The issue is that there are 3 definitions of modulo, two of which are fine (Knuth floored division and Euclidian), and the last one much less useful. Alas, C (%) SQL (MOD) choose the bad definition:-( I really need any of the other two. The attached patch adds all versions, with

Re: [HACKERS] add modulo (%) operator to pgbench

2014-08-06 Thread Fabien COELHO
Hello Alvaro, I wonder if it would be necessary to offer the division operator semantics corresponding to whatever additional modulo operator we choose to offer. That is, if we add emod, do we need ediv as well? I would make sense, however I do not need it, and I'm not sure of a use case

Re: [HACKERS] add modulo (%) operator to pgbench

2014-08-06 Thread Fabien COELHO
Three different modulo operators seems like a lot for a language that doesn't even have a real expression syntax, but I'll yield to whatever the consensus is on this one. Here is a third simpler patch which only implements the Knuth's modulo, where the remainder has the same sign as the

Re: [HACKERS] add modulo (%) operator to pgbench

2014-08-06 Thread Robert Haas
On Tue, Aug 5, 2014 at 5:53 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: Robert Haas wrote: On Mon, Aug 4, 2014 at 5:20 AM, Fabien COELHO coe...@cri.ensmp.fr wrote: This patch is pretty trivial. Another slightly less trivial but more useful version. The issue is that there are 3

Re: [HACKERS] add modulo (%) operator to pgbench

2014-08-06 Thread Fabien COELHO
Maybe we ought to break down and support a real expression syntax. Sounds like that would be better all around. Adding operators is more or less orthogonal with providing a new expression syntax. I'm not sure that there is currently a crying need for it (a syntax). It would be a significant

Re: [HACKERS] add modulo (%) operator to pgbench

2014-08-06 Thread Mitsumasa KONDO
2014-08-06 23:38 GMT+09:00 Fabien COELHO coe...@cri.ensmp.fr: Three different modulo operators seems like a lot for a language that doesn't even have a real expression syntax, but I'll yield to whatever the consensus is on this one. Here is a third simpler patch which only implements the

Re: [HACKERS] add modulo (%) operator to pgbench

2014-08-05 Thread Robert Haas
On Mon, Aug 4, 2014 at 5:20 AM, Fabien COELHO coe...@cri.ensmp.fr wrote: This patch is pretty trivial. Another slightly less trivial but more useful version. The issue is that there are 3 definitions of modulo, two of which are fine (Knuth floored division and Euclidian), and the last one

Re: [HACKERS] add modulo (%) operator to pgbench

2014-08-05 Thread Alvaro Herrera
Robert Haas wrote: On Mon, Aug 4, 2014 at 5:20 AM, Fabien COELHO coe...@cri.ensmp.fr wrote: This patch is pretty trivial. Another slightly less trivial but more useful version. The issue is that there are 3 definitions of modulo, two of which are fine (Knuth floored division and

Re: [HACKERS] add modulo (%) operator to pgbench

2014-08-04 Thread Fabien COELHO
This patch is pretty trivial. Another slightly less trivial but more useful version. The issue is that there are 3 definitions of modulo, two of which are fine (Knuth floored division and Euclidian), and the last one much less useful. Alas, C (%) SQL (MOD) choose the bad definition:-( I