> "Svenne" == Svenne Krap writes:
Svenne> I have the explains,
Can you post the explain analyze outputs?
If need be, you can anonymize the table and column names and any
identifiers by using the anonymization option of explain.depesz.com, but
please only do that if you actually need to.
-
Oh, and I build it on top of f92fc4c95ddcc25978354a8248d3df22269201bc
On 20-04-2015 10:36, Svenne Krap wrote:
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, failed
> Implements feature: tested, passed
> Spec compliant:
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:tested, passed
Hi,
I have (finally) found time to review this.
The syntax is
ok, I will try it using git master branch source code. thanks! Of course, using
gsp-all-latest.patch this time.
At 2015-04-12 14:23:46, "Michael Paquier" wrote:
>On Sun, Apr 12, 2015 at 2:26 PM, 彭瑞华 wrote:
>> I am using postgesql 9.4.0. Thanks for your great work on grouping sets
>> patch ef
On Sun, Apr 12, 2015 at 2:26 PM, 彭瑞华 wrote:
> I am using postgesql 9.4.0. Thanks for your great work on grouping sets
> patch effort.
> I am now compiling postgresql from source code 9.4.0 on Linux platform with
> [gsp-all.patch] successed and grouping function well, but failed on window
> platfo
Dear:
I am using postgesql 9.4.0. Thanks for your great work on grouping sets patch
effort.
I am now compiling postgresql from source code 9.4.0 on Linux platform with
[gsp-all.patch] successed and grouping function well, but failed on window
platform(windows 2003 or window 7).
It shows unreco
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 18-03-2015 17:18, Svenne Krap wrote:
>
> I still need to check against the standard and I will run it against a
non-trivival production load... hopefully I will finish up my review
shortly after the weekend...
I am still on it, but a little dela
> "Svenne" == Svenne Krap writes:
Svenne> I still need to check against the standard and I will run it
Svenne> against a non-trivival production load... hopefully I will
Svenne> finish up my review shortly after the weekend...
Thanks for the review so far; any progress? I'm quite interest
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:tested, passed
This is a midway review, a later will complete it.
The patch ap
Patch from message (87d24iukc5@news-spur.riddles.org.uk) fails (tried to
apply on top of ebc0f5e01d2f ), as b55722692 has broken up the line (in
src/backend/optimizer/util/pathnode.c):
pathnode->path.rows = estimate_num_groups(root, uniq_exprs, rel->rows);
After patching the added parameter
> "Tom" == Tom Lane writes:
>>> Honestly, ChainAggregate is _trivial_ compared to trying to make the
>>> GroupAggregate code deal with multiple inputs, or trying to make some
>>> new sort of plumbing node to feed input to those sorts. (You'd think
>>> that it should be possible to use th
On Tue, Sep 9, 2014 at 12:01 PM, Andrew Gierth
wrote:
>> "Robert" == Robert Haas writes:
>
> Robert> Sure, showing the sort and aggregation steps is fine. But I
> Robert> don't see what advantage we get out of showing them like
> Robert> this:
>
> Robert> Aggregate
> Robert> -> Sort
>
Robert Haas writes:
> On Tue, Sep 9, 2014 at 12:01 PM, Andrew Gierth
> wrote:
>> Honestly, ChainAggregate is _trivial_ compared to trying to make the
>> GroupAggregate code deal with multiple inputs, or trying to make some
>> new sort of plumbing node to feed input to those sorts. (You'd think
>
> "Robert" == Robert Haas writes:
Robert> Sure, showing the sort and aggregation steps is fine. But I
Robert> don't see what advantage we get out of showing them like
Robert> this:
Robert> Aggregate
Robert> -> Sort
Robert>-> ChainAggregate
Robert> -> Sort
Robert>
2014-09-09 16:01 GMT+02:00 Robert Haas :
> On Thu, Aug 21, 2014 at 11:01 AM, Andrew Gierth
> wrote:
> >> "Heikki" == Heikki Linnakangas writes:
> > Heikki> Uh, that's ugly. The EXPLAIN out I mean; as an implementation
> > Heikki> detail chaining the nodes might be reasonable. But the above
On Tue, Sep 9, 2014 at 11:19 AM, Pavel Stehule wrote:
> 2014-09-09 16:01 GMT+02:00 Robert Haas :
>> On Thu, Aug 21, 2014 at 11:01 AM, Andrew Gierth
>> wrote:
>> >> "Heikki" == Heikki Linnakangas writes:
>> > Heikki> Uh, that's ugly. The EXPLAIN out I mean; as an implementation
>> > Heikki>
On Thu, Aug 21, 2014 at 11:01 AM, Andrew Gierth
wrote:
>> "Heikki" == Heikki Linnakangas writes:
> Heikki> Uh, that's ugly. The EXPLAIN out I mean; as an implementation
> Heikki> detail chaining the nodes might be reasonable. But the above
> Heikki> gets unreadable if you have more than a
On Mon, Aug 25, 2014 at 1:35 AM, Andrew Gierth
wrote:
> If you look at the latest patch post, there's a small patch in it that
> does nothing but unreserve the keywords and fix ruleutils to make
> deparse/parse work. The required fix to ruleutils is an example of
> violating your "four kinds of ke
> "Robert" == Robert Haas writes:
Robert> I can accept ugly code, but I feel strongly that we shouldn't
Robert> accept ugly semantics. Forcing cube to get out of the way
Robert> may not be pretty, but I think it will be much worse if we
Robert> violate the rule that quoting a keyword str
> "Tom" == Tom Lane writes:
Tom> I'm not convinced of that; I think some creative hackery in the
Tom> grammar might be able to deal with this.
Making GROUP BY CUBE(a,b) parse as grouping sets rather than as a
function turned out to be the easy part: give CUBE a lower precedence
than '(' (e
* Greg Stark (st...@mit.edu) wrote:
> On Fri, Aug 22, 2014 at 10:37 PM, Stephen Frost wrote:
> > Agreed- and how many of those have *every extension available* loaded...
>
> Actually that was also in the talk.a few slides later. 0.7%
So, 0.3% install cube w/o installing *every* extension..? Tha
On Fri, Aug 22, 2014 at 10:37 PM, Stephen Frost wrote:
> Agreed- and how many of those have *every extension available* loaded...
Actually that was also in the talk.a few slides later. 0.7%
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
* Andrew Dunstan (and...@dunslane.net) wrote:
>
> On 08/22/2014 02:42 PM, Greg Stark wrote:
> >On Fri, Aug 22, 2014 at 7:02 PM, Tom Lane wrote:
> >>So the proposal you are pushing is going
> >>to result in seriously teeing off some fraction of our userbase;
> >>and the argument why that would be
On Fri, Aug 22, 2014 at 1:52 PM, Robert Haas wrote:
> On Fri, Aug 22, 2014 at 2:02 PM, Tom Lane wrote:
> https://www.youtube.com/watch?v=MT2gzzbyWpw
>
> At around 8 minutes, he shows utilization statistics for cube at
> around 1% across their install base. That's higher than I would have
> guess
On 08/22/2014 02:42 PM, Greg Stark wrote:
On Fri, Aug 22, 2014 at 7:02 PM, Tom Lane wrote:
So the proposal you are pushing is going
to result in seriously teeing off some fraction of our userbase;
and the argument why that would be acceptable seems to boil down to
"I think there are few enough
On Fri, Aug 22, 2014 at 2:02 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Aug 21, 2014 at 2:13 PM, Tom Lane wrote:
>>> Well, if there are any extant applications that use that exact phrasing,
>>> they're going to be broken in any case. That does not mean that we have
>>> to break every
On Fri, Aug 22, 2014 at 7:02 PM, Tom Lane wrote:
> So the proposal you are pushing is going
> to result in seriously teeing off some fraction of our userbase;
> and the argument why that would be acceptable seems to boil down to
> "I think there are few enough of them that we don't have to care"
>
Robert Haas writes:
> On Thu, Aug 21, 2014 at 2:13 PM, Tom Lane wrote:
>> Well, if there are any extant applications that use that exact phrasing,
>> they're going to be broken in any case. That does not mean that we have
>> to break every other appearance of "cube". I think that special-casing
On Thu, Aug 21, 2014 at 2:13 PM, Tom Lane wrote:
> Andrew Gierth writes:
>> "Tom" == Tom Lane writes:
>> Tom> I wonder if you've tried hard enough to avoid reserving the keyword.
>
>> GROUP BY cube(a,b) is currently legal syntax and means something completely
>> incompatible to what the spec r
> "Alvaro" == Alvaro Herrera writes:
>> (This of course means that if someone has a cube() function call
>> in a group by clause of a view, then upgrading will change the
>> meaning of the view and possibly fail to create it; there seems to
>> be no fix for this, not even using the latest
Andrew Gierth wrote:
> (This of course means that if someone has a cube() function call in
> a group by clause of a view, then upgrading will change the meaning
> of the view and possibly fail to create it; there seems to be no fix
> for this, not even using the latest pg_dump, since pg_dump relie
* Andrew Gierth (and...@tao11.riddles.org.uk) wrote:
> Having now spent some more time looking, I believe there is a solution
> which makes it unreserved which does not require any significant pain
> in the code. I'm not entirely convinced that this is the right
> approach in the long term, but it
> "Tom" == Tom Lane writes:
Tom> Perhaps so. I would really prefer not to have to get into
Tom> estimating how many people will be inconvenienced how badly.
Tom> It's clear to me that not a lot of sweat has been put into
Tom> seeing if we can avoid reserving the keyword, and I think we
> "Stephen" == Stephen Frost writes:
>>> I'm inclined to think that the audience for this is far larger
>>> than the audience for the cube extension, which I have not once
>>> encountered in the field.
Stephen> +1
Most of my encounters with cube have been me suggesting it to people
on I
On Thu, Aug 21, 2014 at 06:15:33PM -0400, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Andrew Dunstan writes:
> > > I'm inclined to think that the audience for this is far larger than the
> > > audience for the cube extension, which I have not once encountered in
> > > the f
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Andrew Dunstan writes:
> > I'm inclined to think that the audience for this is far larger than the
> > audience for the cube extension, which I have not once encountered in
> > the field.
+1
> Perhaps so. I would really prefer not to have to get into e
Andrew Dunstan writes:
> I'm inclined to think that the audience for this is far larger than the
> audience for the cube extension, which I have not once encountered in
> the field.
Perhaps so. I would really prefer not to have to get into estimating
how many people will be inconvenienced how
On 08/21/2014 02:48 PM, Merlin Moncure wrote:
Basically, I'm afraid that unilaterally renaming cube is going to break
enough applications that there will be more people who flat out don't
want this patch than there will be who get benefit from it, and we end
up voting to revert the feature alto
On Thu, Aug 21, 2014 at 1:13 PM, Tom Lane wrote:
> Andrew Gierth writes:
>> "Tom" == Tom Lane writes:
>> Tom> I wonder if you've tried hard enough to avoid reserving the keyword.
>
>> GROUP BY cube(a,b) is currently legal syntax and means something completely
>> incompatible to what the spec r
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> I wonder if you've tried hard enough to avoid reserving the keyword.
> GROUP BY cube(a,b) is currently legal syntax and means something completely
> incompatible to what the spec requires.
Well, if there are any extant applications that
2014-08-21 17:58 GMT+02:00 Andrew Gierth :
> > "Tom" == Tom Lane writes:
>
> >> I agree, the contrib/cube patch as posted is purely so we could test
> >> everything without having to argue over the new name first.
>
> Tom> I wonder if you've tried hard enough to avoid reserving the keyword
> "Tom" == Tom Lane writes:
>> I agree, the contrib/cube patch as posted is purely so we could test
>> everything without having to argue over the new name first.
Tom> I wonder if you've tried hard enough to avoid reserving the keyword.
GROUP BY cube(a,b) is currently legal syntax and m
2014-08-21 17:00 GMT+02:00 Tom Lane :
> Andrew Gierth writes:
> > "Heikki" == Heikki Linnakangas writes:
> > Heikki> I think we should bite the bullet and rename the extension,
>
> > I agree, the contrib/cube patch as posted is purely so we could test
> > everything without having to argue over
> "Heikki" == Heikki Linnakangas writes:
Heikki> Uh, that's ugly. The EXPLAIN out I mean; as an implementation
Heikki> detail chaining the nodes might be reasonable. But the above
Heikki> gets unreadable if you have more than a few grouping sets.
It's good for highlighting performance iss
Andrew Gierth writes:
> "Heikki" == Heikki Linnakangas writes:
> Heikki> I think we should bite the bullet and rename the extension,
> I agree, the contrib/cube patch as posted is purely so we could test
> everything without having to argue over the new name first.
I wonder if you've tried har
On 08/21/2014 01:28 PM, Andrew Gierth wrote:
A progress update:
Atri> We envisage that handling of arbitrary grouping sets will be
Atri> best done by having the planner generating an Append of
Atri> multiple aggregation paths, presumably with some way of moving
Atri> the original input
A progress update:
Atri> We envisage that handling of arbitrary grouping sets will be
Atri> best done by having the planner generating an Append of
Atri> multiple aggregation paths, presumably with some way of moving
Atri> the original input path to a CTE. We have not really explored
Atri>
> "Heikki" == Heikki Linnakangas writes:
> On 08/13/2014 09:43 PM, Atri Sharma wrote:
>> Sorry, forgot to attach the patch for fixing cube in contrib,
>> which breaks since we now reserve "cube" keyword. Please find
>> attached the same.
Heikki> Ugh, that will make everyone using the cu
On 08/13/2014 09:43 PM, Atri Sharma wrote:
Sorry, forgot to attach the patch for fixing cube in contrib, which breaks
since we now reserve "cube" keyword. Please find attached the same.
Ugh, that will make everyone using the cube extension unhappy. After
this patch, they will have to quote con
49 matches
Mail list logo
