Dean Rasheed writes:
> Fair enough. I have no further comments.
Pushed then. Thanks for reviewing! I gave you credit as co-author.
regards, tom lane
On Tue, 19 Mar 2024 at 21:40, Tom Lane wrote:
>
> I'm inclined to leave that alone. The actual source sub-SELECT
> could only have had one column, so no real confusion is possible.
> Yeah, there's a resjunk grouping column visible in the plan as well,
> but those exist in many other queries, and
Dean Rasheed writes:
> One final case that could possibly be improved is this one from
> aggregates.out:
> explain (verbose, costs off)
> select array(select sum(x+y) s
> from generate_series(1,3) y group by y order by s)
> from generate_series(1,3) x;
>
On Tue, 19 Mar 2024 at 16:42, Tom Lane wrote:
>
> Here's a hopefully-final version that makes that adjustment and
> tweaks a couple of comments.
>
This looks very good to me.
One final case that could possibly be improved is this one from aggregates.out:
explain (verbose, costs off)
select
I wrote:
> I won't update the patch right now, but "(rescan SubPlan N)"
> seems like a winner to me.
Here's a hopefully-final version that makes that adjustment and
tweaks a couple of comments.
regards, tom lane
diff --git a/contrib/postgres_fdw/expected/postgres_fdw.out
Dean Rasheed writes:
> On Mon, 18 Mar 2024 at 23:19, Tom Lane wrote:
>> After thinking a bit more, I understood what was bothering me about
>> that notation: it looks too much like a call of a user-defined
>> function named "rescan()". I think we'd be better off with the
>> all-caps "RESCAN()".
On Mon, 18 Mar 2024 at 23:19, Tom Lane wrote:
>
> > Hm. I used "rescan(SubPlan)" in the attached, but it still looks
> > a bit odd to my eye.
>
> After thinking a bit more, I understood what was bothering me about
> that notation: it looks too much like a call of a user-defined
> function named
I wrote:
> Hm. I used "rescan(SubPlan)" in the attached, but it still looks
> a bit odd to my eye.
After thinking a bit more, I understood what was bothering me about
that notation: it looks too much like a call of a user-defined
function named "rescan()". I think we'd be better off with the
Dean Rasheed writes:
> The get_rule_expr() code could perhaps be simplified a bit, getting
> rid of the show_subplan_name variable and moving the recursive calls
> to get_rule_expr() to after the switch statement -- if testexpr is
> non-NULL, print it, else print the subplan name probably works
On Sun, 17 Mar 2024 at 19:39, Tom Lane wrote:
>
> Here's a cleaned-up version that seems to successfully resolve
> PARAM_EXEC references in all cases. I haven't changed the
> "(plan_name).colN" notation, but that's an easy fix once we have
> consensus on the spelling.
I took a more detailed
I wrote:
> Dean Rasheed writes:
>> Overall, I think this is heading in the right direction. I think we
>> just need a good way to say "the n'th output column of the subplan",
>> that can't be confused with anything else in the output.
> We could consider notations like "(SubPlan 1 column 2)",
Dean Rasheed writes:
> On Sat, 16 Mar 2024 at 17:25, Tom Lane wrote:
>> After looking at your draft some more, it occurred to me that we're
>> not that far from getting rid of showing "$n" entirely in this
>> context. Instead of (subplan_name).$n, we could write something like
>>
On Sat, 16 Mar 2024 at 17:25, Tom Lane wrote:
>
> After looking at your draft some more, it occurred to me that we're
> not that far from getting rid of showing "$n" entirely in this
> context. Instead of (subplan_name).$n, we could write something like
> (subplan_name).colN or
I wrote:
> Dean Rasheed writes:
>> One thing that concerns me about making even greater use of "$n" is
>> the potential for confusion with generic plan parameters.
> True.
After looking at your draft some more, it occurred to me that we're
not that far from getting rid of showing "$n" entirely
Dean Rasheed writes:
> One thing that concerns me about making even greater use of "$n" is
> the potential for confusion with generic plan parameters.
True.
> Another possibility is to put the SubPlan and InitPlan names inline,
> rather than outputting "FROM SubPlan ...". I had a go at hacking
On Fri, 16 Feb 2024 at 19:39, Tom Lane wrote:
>
> > So now I'm thinking that we do have enough detail in the present
> > proposal, and we just need to think about whether there's some
> > nicer way to present it than the particular spelling I used here.
>
One thing that concerns me about making
> On 17 Feb 2024, at 00:38, Tom Lane wrote:
>
> Here's a rebase over 9f1337639 --- no code changes, but this affects
> some of the new or changed expected outputs from that commit.
Aleksander, as long as your was reviewing this previously, I’ve added you to
reviewers of this CF entry [0].
I wrote:
> So now I'm thinking that we do have enough detail in the present
> proposal, and we just need to think about whether there's some
> nicer way to present it than the particular spelling I used here.
Here's a rebase over 9f1337639 --- no code changes, but this affects
some of the new or
I wrote:
> The main thing that's still missing compared to what is in the plan
> data structure is information about which Param is which. I think
> we have the subplan output Params relatively well covered through
> the expedient of listing them in the generated plan_name, but it's
> still not
Hi Aleksander and Tom
I do confirm that I requested to get this information, in order to
recover the formula to filter on.
Thanks to both of you
Chantal
Le 22/01/2024 à 18:07, Tom Lane a écrit :
Aleksander Alekseev writes:
Although something like:
```
+ Filter: (ANY (base_tbl.a =
Aleksander Alekseev writes:
> Although something like:
> ```
> + Filter: (ANY (base_tbl.a = $1) FROM SubPlan 1 (returns $1))
> + SubPlan 1 (returns $1)
> ```
> ... arguably doesn't give much more information to the user comparing
> to what we have now:
> ```
> - Filter: (SubPlan 1)
> -
Hi,
> EXPLAIN has always been really poor at displaying SubPlan nodes
> in expressions: you don't get much more than "(SubPlan N)".
> This is mostly because every time I thought about it, I despaired
> of trying to represent all the information in a SubPlan accurately.
> However, a recent
EXPLAIN has always been really poor at displaying SubPlan nodes
in expressions: you don't get much more than "(SubPlan N)".
This is mostly because every time I thought about it, I despaired
of trying to represent all the information in a SubPlan accurately.
However, a recent discussion[1] made me
23 matches
Mail list logo
