On 28 April 2016 at 04:08, Robert Haas wrote:
> On Tue, Apr 26, 2016 at 11:38 PM, David Rowley
>> The patch looks good. The only other thing I thought about was perhaps
>> it would be a good idea to re-add the sanity checks in execQual.c.
>> Patch for that is attached.
>>
>> I removed the aggoutpu
On Tue, Apr 26, 2016 at 11:38 PM, David Rowley
wrote:
> On 27 April 2016 at 15:12, Robert Haas wrote:
>> On Tue, Apr 26, 2016 at 10:57 PM, David Rowley
>> wrote:
>>> On 27 April 2016 at 14:30, Robert Haas wrote:
On Tue, Apr 26, 2016 at 9:56 PM, Robert Haas wrote:
> On Tue, Apr 26, 201
On 27 April 2016 at 15:12, Robert Haas wrote:
> On Tue, Apr 26, 2016 at 10:57 PM, David Rowley
> wrote:
>> On 27 April 2016 at 14:30, Robert Haas wrote:
>>> On Tue, Apr 26, 2016 at 9:56 PM, Robert Haas wrote:
On Tue, Apr 26, 2016 at 9:14 PM, David Rowley
wrote:
> I'd also have ex
On Tue, Apr 26, 2016 at 10:57 PM, David Rowley
wrote:
> On 27 April 2016 at 14:30, Robert Haas wrote:
>> On Tue, Apr 26, 2016 at 9:56 PM, Robert Haas wrote:
>>> On Tue, Apr 26, 2016 at 9:14 PM, David Rowley
>>> wrote:
I'd also have expected the output of both partial nodes to be the
s
On 2016-04-27 14:57:24 +1200, David Rowley wrote:
> "private" is reserved in C++? I understood we want our C code to
> compile as C++ too, right? or did I get my wires crossed somewhere?
Just headers. Our C code unfortunately is very far away from being C++
compliant.
--
Sent via pgsql-hackers
On 27 April 2016 at 14:30, Robert Haas wrote:
> On Tue, Apr 26, 2016 at 9:56 PM, Robert Haas wrote:
>> On Tue, Apr 26, 2016 at 9:14 PM, David Rowley
>> wrote:
>>> I'd also have expected the output of both partial nodes to be the
>>> same, i.e. both prefixed with PARTIAL. Is it intended that they
On Tue, Apr 26, 2016 at 9:56 PM, Robert Haas wrote:
> On Tue, Apr 26, 2016 at 9:14 PM, David Rowley
> wrote:
>> I'd also have expected the output of both partial nodes to be the
>> same, i.e. both prefixed with PARTIAL. Is it intended that they don't?
>> or have I made some other mistake?
>
> No,
On Tue, Apr 26, 2016 at 9:14 PM, David Rowley
wrote:
> I'd also have expected the output of both partial nodes to be the
> same, i.e. both prefixed with PARTIAL. Is it intended that they don't?
> or have I made some other mistake?
No, that's a defect in the patch. I didn't consider that we need
On 27 April 2016 at 12:37, Robert Haas wrote:
> On Tue, Apr 26, 2016 at 6:44 PM, David Rowley
> wrote:
>> On 27 April 2016 at 08:46, Robert Haas wrote:
>>> My proposed fix for this issue is attached. Review is welcome;
>>> otherwise, I'll just commit this. The output looks like what I
>>> sugg
On Tue, Apr 26, 2016 at 6:44 PM, David Rowley
wrote:
> On 27 April 2016 at 08:46, Robert Haas wrote:
>> My proposed fix for this issue is attached. Review is welcome;
>> otherwise, I'll just commit this. The output looks like what I
>> suggested upthread:
>
> + if (!aggref->aggpartial)
> + elog
On 27 April 2016 at 08:46, Robert Haas wrote:
> My proposed fix for this issue is attached. Review is welcome;
> otherwise, I'll just commit this. The output looks like what I
> suggested upthread:
+ if (!aggref->aggpartial)
+ elog(ERROR, "referenced Aggref is not partial");
I think this is ov
Robert Haas writes:
> My proposed fix for this issue is attached. Review is welcome;
> otherwise, I'll just commit this. The output looks like what I
> suggested upthread:
I haven't read the patch, but the sample output looks sane.
regards, tom lane
--
Sent via pgsql
On Mon, Apr 25, 2016 at 1:03 PM, Robert Haas wrote:
> Yeah, I'd be happy to have more people chime in. I think your example
> is interesting, but it doesn't persuade me, because the rule has
> always been that EXPLAIN shows the output *columns*, not the output
> *rows*. The disappearance of some
On Fri, Apr 22, 2016 at 10:11 PM, David Rowley
wrote:
> The most basic thing I can think of to rationalise my thinking for this is:
>
> # create table v (v varchar);
> # create view v_v as select lower(v) v from v;
> # explain verbose select upper(v) from v_v;
> QUERY PLAN
On 23 April 2016 at 13:58, Robert Haas wrote:
> On Fri, Apr 22, 2016 at 5:36 PM, David Rowley
> wrote:
>> I really don't think that we should print FILTER details in a combine
>> aggregate node. We'd be claiming to be doing something that we're
>> actually not doing. Please see advance_aggregates
On Fri, Apr 22, 2016 at 5:36 PM, David Rowley
wrote:
> I really don't think that we should print FILTER details in a combine
> aggregate node. We'd be claiming to be doing something that we're
> actually not doing. Please see advance_aggregates() in nodeAgg.c, and
> compare that to combine_aggrega
On 23 April 2016 at 09:19, Robert Haas wrote:
> 2. Add a field "bool aggcombine" to args, and set it to true in this
> case. When we see that in deparsing, expect the argument list to be
> one element long, a TargetEntry containing a Var. Use that to dig out
> the partial Aggref to which it poin
On 23 April 2016 at 06:35, Robert Haas wrote:
> 2. You're using the term "combine agg", but as far as the EXPLAIN
> ANALYZE output is concerned, that's not a thing. There is
> PartialAggregate, Aggregate, and FinalizeAggregate. I think you mean
> FinalizeAggregate when you say "combine aggregate
On Sun, Apr 17, 2016 at 10:22 AM, Tom Lane wrote:
> David Rowley writes:
>> On 16 April 2016 at 04:27, Tom Lane wrote:
>>> +1 for the latter, if we can do it conveniently. I think exposing
>>> the names of the aggregate implementation functions would be very
>>> user-unfriendly, as nobody but u
On Thu, Apr 21, 2016 at 8:57 PM, David Rowley
wrote:
> OK, so here's my thoughts. Currently, as mentioned above, I've
> included a PARTIAL prefix for partial aggregates. This is
> syntactically incorrect for the dumping of views etc, but that should
> not matter as partial Aggrefs never come from
On 21 April 2016 at 17:14, Tom Lane wrote:
> David Rowley writes:
>> I'd like to admit that I'm a bit confused as to why
>> generate_function_name(), when it already knows the funcid, bothers to
>> call func_get_detail(), which performs a search for the function based
>> on the name and argument
David Rowley writes:
> I'd like to admit that I'm a bit confused as to why
> generate_function_name(), when it already knows the funcid, bothers to
> call func_get_detail(), which performs a search for the function based
> on the name and argument types, to find the function, most likely with
> th
On 18 April 2016 at 02:22, Tom Lane wrote:
> David Rowley writes:
>> Note that I've done nothing for the weird schema prefixing problem I
>> mentioned. I think I'd need input on the best way to solve this. If
>> it's actually a problem.
>
> It sure looks like a problem to me. Maybe it's only cos
On Tue, Apr 19, 2016 at 9:22 PM, Noah Misch wrote:
> On Sun, Apr 17, 2016 at 10:22:24AM -0400, Tom Lane wrote:
>> David Rowley writes:
>> > On 16 April 2016 at 04:27, Tom Lane wrote:
>> >> +1 for the latter, if we can do it conveniently. I think exposing
>> >> the names of the aggregate impleme
On Sun, Apr 17, 2016 at 10:22:24AM -0400, Tom Lane wrote:
> David Rowley writes:
> > On 16 April 2016 at 04:27, Tom Lane wrote:
> >> +1 for the latter, if we can do it conveniently. I think exposing
> >> the names of the aggregate implementation functions would be very
> >> user-unfriendly, as n
David Rowley writes:
> On 16 April 2016 at 04:27, Tom Lane wrote:
>> +1 for the latter, if we can do it conveniently. I think exposing
>> the names of the aggregate implementation functions would be very
>> user-unfriendly, as nobody but us hackers knows what those are.
> It does not really see
On 16 April 2016 at 04:27, Tom Lane wrote:
> Robert Haas writes:
>> I definitely agree that the current output is messed up, but I'm not
>> sure your proposed output is much better. I wonder if it shouldn't
>> say something like:
>> Output: serialfn(transfn(args))
>> for the partial aggregate an
Robert Haas writes:
> I definitely agree that the current output is messed up, but I'm not
> sure your proposed output is much better. I wonder if it shouldn't
> say something like:
> Output: serialfn(transfn(args))
> for the partial aggregate and
> Output: finalfn(combinefn(deserialfn(args)))
>
On Wed, Apr 13, 2016 at 11:03 PM, David Rowley
wrote:
> There's 2 problems:
>
> 1)
>
> I recently noticed that EXPLAIN VERBOSE is a bit bogus when it comes
> to parallel aggregates with FILTER (WHERE ...) clauses.
>
> We get;
>
> Output: pg_catalog.sum((sum(num) FILTER (WHERE (num > 0 FILTER
>
There's 2 problems:
1)
I recently noticed that EXPLAIN VERBOSE is a bit bogus when it comes
to parallel aggregates with FILTER (WHERE ...) clauses.
We get;
Output: pg_catalog.sum((sum(num) FILTER (WHERE (num > 0 FILTER
(WHERE (num > 0))
Which is simply a lie, we only filter on the partial
30 matches
Mail list logo
