Tomas == Tomas Vondra t...@fuzzy.cz writes:
Tomas If we can get rid of the excessive ChainAggregate, that's
Tomas certainly enough for now.
I found an algorithm that should provably give the minimal number of sorts
(I was afraid that problem would turn out to be NP-hard, but not so - it's
On 6.9.2014 23:34, Andrew Gierth wrote:
Tomas == Tomas Vondra t...@fuzzy.cz writes:
Tomas I have significant doubts about the whole design,
Tomas though. Especially the decision not to use HashAggregate,
There is no decision not to use HashAggregate. There is simply no
support for
Tomas == Tomas Vondra t...@fuzzy.cz writes:
It's not one sort per grouping set, it's the minimal number of
sorts needed to express the result as a union of ROLLUP
clauses. The planner code will (I believe) always find the
smallest number of sorts needed.
Tomas You're probably right.
On 7.9.2014 15:11, Andrew Gierth wrote:
Tomas == Tomas Vondra t...@fuzzy.cz writes:
It's not one sort per grouping set, it's the minimal number of
sorts needed to express the result as a union of ROLLUP
clauses. The planner code will (I believe) always find the
smallest number of
Tomas == Tomas Vondra t...@fuzzy.cz writes:
As for computing it all twice, there's currently no attempt to
optimize multiple identical grouping sets into multiple
projections of a single grouping set result. CUBE(a,b,c,a) has
twice as many grouping sets as CUBE(a,b,c) does, even though
On 7.9.2014 18:52, Andrew Gierth wrote:
Tomas == Tomas Vondra t...@fuzzy.cz writes:
Tomas Maybe preventing this completely (i.e. raising an ERROR with
Tomas duplicate columns in CUBE/ROLLUP/... clauses) would be
Tomas appropriate. Does the standard says anything about this?
The spec
On 31.8.2014 22:52, Andrew Gierth wrote:
Recut patches:
gsp1.patch - phase 1 code patch (full syntax, limited functionality)
gsp2.patch - phase 2 code patch (adds full functionality using the
new chained aggregate mechanism)
gsp-doc.patch - docs
Tomas == Tomas Vondra t...@fuzzy.cz writes:
Tomas I have significant doubts about the whole design,
Tomas though. Especially the decision not to use HashAggregate,
There is no decision not to use HashAggregate. There is simply no
support for HashAggregate yet.
Having it be able to work with
On Tue, August 26, 2014 14:24, Andrew Gierth wrote:
Erik == Erik Rijkers e...@xs4all.nl writes:
They apply cleanly for me at 2bde297 whether with git apply or
patch, except for the contrib one (which you don't need unless you
want to run the contrib regression tests without applying the
On Sun, Aug 31, 2014 at 9:07 PM, Erik Rijkers e...@xs4all.nl wrote:
On Tue, August 26, 2014 14:24, Andrew Gierth wrote:
Erik == Erik Rijkers e...@xs4all.nl writes:
They apply cleanly for me at 2bde297 whether with git apply or
patch, except for the contrib one (which you don't need
On 2014-08-31 21:09:59 +0530, Atri Sharma wrote:
On Sun, Aug 31, 2014 at 9:07 PM, Erik Rijkers e...@xs4all.nl wrote:
I have found that the unrecognized node type error is caused by:
It's a warning, not an error, right?
shared_preload_libraries = pg_stat_statements
in postgresql.conf (as
On Sunday, August 31, 2014, Andres Freund and...@2ndquadrant.com wrote:
On 2014-08-31 21:09:59 +0530, Atri Sharma wrote:
On Sun, Aug 31, 2014 at 9:07 PM, Erik Rijkers e...@xs4all.nl
javascript:; wrote:
I have found that the unrecognized node type error is caused by:
It's a warning, not
On Mon, August 25, 2014 07:21, Andrew Gierth wrote:
Here is the new version of our grouping sets patch. This version
supersedes the previous post.
The patches did not apply anymore so I applied at 73eba19aebe0. There they
applied OK, and make make check was OK.
drop table if exists
Erik == Erik Rijkers e...@xs4all.nl writes:
Erik The patches did not apply anymore so I applied at 73eba19aebe0.
Erik There they applied OK, and make make check was OK.
I'll look and rebase if need be.
-- WARNING: unrecognized node type: 347
Can't reproduce this - are you sure it's not a
Andrew == Andrew Gierth and...@tao11.riddles.org.uk writes:
Erik == Erik Rijkers e...@xs4all.nl writes:
Erik The patches did not apply anymore so I applied at 73eba19aebe0.
Erik There they applied OK, and make make check was OK.
Andrew I'll look and rebase if need be.
They apply cleanly
On Tue, August 26, 2014 11:13, Andrew Gierth wrote:
Andrew == Andrew Gierth and...@tao11.riddles.org.uk writes:
Erik == Erik Rijkers e...@xs4all.nl writes:
Erik The patches did not apply anymore so I applied at 73eba19aebe0.
Erik There they applied OK, and make make check was OK.
Erik == Erik Rijkers e...@xs4all.nl writes:
They apply cleanly for me at 2bde297 whether with git apply or
patch, except for the contrib one (which you don't need unless you
want to run the contrib regression tests without applying the
gsp-u patch).
Erik Ah, I had not realised that.
On Tue, August 26, 2014 14:24, Andrew Gierth wrote:
Erik == Erik Rijkers e...@xs4all.nl writes:
They apply cleanly for me at 2bde297 whether with git apply or
patch, except for the contrib one (which you don't need unless you
want to run the contrib regression tests without applying the
18 matches
Mail list logo
