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
On Sat, Aug 22, 2009 at 1:37 AM, Tom Lane wrote:
> You can see that from the fact that the estimated row width is
> 8 bytes (two integers) ... but tenthous is nowhere to be seen in the
> Output: line.
+1 for self-consistent output. If we're including their size in
"width" then they should be in th
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Currently, explain.c goes out of its way to not print "resjunk" output
> columns (those not meant to be seen by the user, such as hidden sort key
> columns) in EXPLAIN VERBOSE targetlists. I made 8.4 act that way for
> reasons I don't recall at the moment,
Currently, explain.c goes out of its way to not print "resjunk" output
columns (those not meant to be seen by the user, such as hidden sort key
columns) in EXPLAIN VERBOSE targetlists. I made 8.4 act that way for
reasons I don't recall at the moment, but I've found several times now
that it's misl
"Cristiano Duarte" <[EMAIL PROTECTED]> wrote
> Does anyone know how to discover the tables (with schemas or oid)
> involved
> on a select statement?
> I tried EXPLAIN but it only reports the table names, not schemas or
> oid.
>
In general, this is a pretty difficult problem - thinking you may d
Does anyone know how to discover the tables (with schemas or oid) involved
on a select statement?
I tried EXPLAIN but it only reports the table names, not schemas or oid.
I am developing a SNAPSHOT project for PostgreSQL called Pg::snapshots. It
can be found here:
http://cunha17.theicy.net/person
35 matches
Mail list logo
