On Mon, Mar 2, 2015 at 5:41 PM, Fabien COELHO 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 about where the is
On Mon, Mar 2, 2015 at 5:41 PM, Fabien COELHO 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 about where
Hello Robert,
Done.
Great!
I removed some of the new error-reporting stuff because (1) I wasn't
sure it was right
Hmmm. Although I'm not sure it was right, I'm sure that not enough error
reporting is too rough:
sh> ./pgbench -f bad.sql
syntax error at column 25
set: parse error
On Sun, Mar 1, 2015 at 1:42 PM, Robert Haas wrote:
> On Sat, Feb 28, 2015 at 12:06 PM, Stephen Frost 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.
On Sat, Feb 28, 2015 at 12:06 PM, Stephen Frost 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 Review" since that'
* Fabien COELHO (coe...@cri.ensmp.fr) wrote:
>
> >On Mon, Jan 5, 2015 at 10:37 AM, Fabien COELHO 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 pe
On Mon, Jan 5, 2015 at 10:37 AM, Fabien COELHO 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 and improve it. There
On Mon, Jan 5, 2015 at 10:37 AM, Fabien COELHO 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 and improve it. There
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 that
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
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 say
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
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 define
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 the
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 simplest
On 1 January 2015 at 21:23, Fabien COELHO 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 careful not
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
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 na
On 1 January 2015 at 21:23, Fabien COELHO 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 seeing some
impro
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
+++ b/contr
On 1 January 2015 at 04:02, Fabien COELHO 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 this, but I
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 100
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
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 while
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 pgsql-h
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
wrote:
Sigh.
How to transform a trivial 10 lines patch into a probably 500+ lines
project
involving flex & bison & some non trivial data structures, an
On 09/25/2014 05:10 AM, Robert Haas wrote:
On Wed, Sep 24, 2014 at 2:34 PM, Fabien COELHO 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
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 u
On Thu, Sep 25, 2014 at 1:27 AM, Gregory Smith 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
> parser mountains
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% error.
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 m
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
On Wed, Sep 24, 2014 at 2:34 PM, Fabien COELHO 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 project.
I
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,
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...
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,
Kevin Grittner 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) / abs(b).
>
Fabien COELHO 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 have.
>
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 0
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 gaus
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 e
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
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Fabien COELHO 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 se
Fabien COELHO 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 have.
So I'm incli
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 rea
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
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 ]
Th
On Thu, Sep 11, 2014 at 2:47 AM, Fabien COELHO 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 add abs(x) or ha
2014-09-11 15:47 GMT+09:00 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'
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 gr
On Wed, Sep 10, 2014 at 4:48 AM, Fabien COELHO 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 not
> enough, but
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 wo
On Tue, Sep 9, 2014 at 11:07 AM, Fabien COELHO 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 version which
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 c
On Wed, Aug 6, 2014 at 3:22 PM, Fabien COELHO 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 is currently
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 make
Hi Fabien-san,
Thank you for your fast work!
2014-09-08 23:08 GMT+09:00 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 sim
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
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 prop
2014-08-06 23:38 GMT+09:00 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 mo
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
On Tue, Aug 5, 2014 at 5:53 PM, Alvaro Herrera wrote:
> Robert Haas wrote:
>> On Mon, Aug 4, 2014 at 5:20 AM, Fabien COELHO 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
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 divis
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
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
Robert Haas wrote:
> On Mon, Aug 4, 2014 at 5:20 AM, Fabien COELHO 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
On Mon, Aug 4, 2014 at 5:20 AM, Fabien COELHO 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 much less useful.
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
This patch is pretty trivial.
Add modulo operator to pgbench.
This is useful to compute a permutation for tests with non uniform
accesses (exponential or gaussian), so as to avoid trivial correlations
between neighbour keys.
--
Fabien.diff --git a/contrib/pgbench/pgbench.c b/contrib/pgbench
69 matches
Mail list logo
