I wrote:
> OK, so here's a finished set of patches for this issue.
> 0001 is the same patch I posted on Tuesday; I kept it separate just
> because it seemed like a largely separable set of changes. (Note that
> the undesirable regression test output changes are undone by 0002.)
> 0002 implements
I wrote:
>> This may be arguing for a change in ruleutils' existing behavior,
>> not sure. But when dealing with traditional-style inheritance,
>> I've always thought that Vars above the Append were referring to
>> the parent rel in its capacity as the parent, not in its capacity
>> as the first
Alvaro Herrera writes:
> On 2019-Jul-30, Tom Lane wrote:
>> The portion of this below the Append is fine, but I argue that
>> the Vars above the Append should say "part", not "part_p1".
>> In that way they'd look the same regardless of which partitions
>> have been pruned or not.
> So is anyone
On Sat, Nov 30, 2019 at 09:43:35PM -0500, Tom Lane wrote:
> Fair enough, but I did actually spend some time on the issue today.
> Just to cross-link this thread to the latest, see
>
> https://www.postgresql.org/message-id/12424.1575168015%40sss.pgh.pa.us
Thanks, just saw the update.
--
Michael
Michael Paquier writes:
> On Thu, Sep 12, 2019 at 10:24:13AM -0400, Tom Lane wrote:
>> It's on my to-do list, but I'm not sure how soon I'll get to it.
> Seems like it is better to mark this CF entry as returned with
> feedback then.
Fair enough, but I did actually spend some time on the issue
On Thu, Sep 12, 2019 at 10:24:13AM -0400, Tom Lane wrote:
> It's on my to-do list, but I'm not sure how soon I'll get to it.
Seems like it is better to mark this CF entry as returned with
feedback then.
--
Michael
signature.asc
Description: PGP signature
Alvaro Herrera writes:
> So is anyone working on a patch to use this approach?
It's on my to-do list, but I'm not sure how soon I'll get to it.
regards, tom lane
On 2019-Jul-30, Tom Lane wrote:
> I wrote:
> > This may be arguing for a change in ruleutils' existing behavior,
> > not sure. But when dealing with traditional-style inheritance,
> > I've always thought that Vars above the Append were referring to
> > the parent rel in its capacity as the
On Wed, Jul 31, 2019 at 8:31 AM Tom Lane wrote:
> David Rowley writes:
> > On Wed, 31 Jul 2019 at 10:56, Tom Lane wrote:
> >> The portion of this below the Append is fine, but I argue that
> >> the Vars above the Append should say "part", not "part_p1".
> >> In that way they'd look the same
David Rowley writes:
> On Wed, 31 Jul 2019 at 10:56, Tom Lane wrote:
>> The portion of this below the Append is fine, but I argue that
>> the Vars above the Append should say "part", not "part_p1".
>> In that way they'd look the same regardless of which partitions
>> have been pruned or not.
>
On Wed, 31 Jul 2019 at 10:56, Tom Lane wrote:
>
> OK, so experimenting, I see that it is a change: HEAD does
>
> regression=# explain verbose select * from part order by a;
>QUERY PLAN
>
I wrote:
> This may be arguing for a change in ruleutils' existing behavior,
> not sure. But when dealing with traditional-style inheritance,
> I've always thought that Vars above the Append were referring to
> the parent rel in its capacity as the parent, not in its capacity
> as the first
David Rowley writes:
> On Wed, 31 Jul 2019 at 10:27, Tom Lane wrote:
>> What I had in mind was to revert 1cc29fe7c's ruleutils changes
>> entirely, so that ruleutils deals only in Plans not PlanStates.
>> Perhaps we've grown some code since then that really needs the
>> PlanStates, but what is
On Wed, 31 Jul 2019 at 10:27, Tom Lane wrote:
>
> David Rowley writes:
> > The part I wouldn't mind another set of eyes on is the ruleutils.c
> > changes.
>
> Um, sorry for not getting to this sooner.
>
> What I had in mind was to revert 1cc29fe7c's ruleutils changes
> entirely, so that
David Rowley writes:
> The part I wouldn't mind another set of eyes on is the ruleutils.c
> changes.
Um, sorry for not getting to this sooner.
What I had in mind was to revert 1cc29fe7c's ruleutils changes
entirely, so that ruleutils deals only in Plans not PlanStates.
Perhaps we've grown some
On Sat, 25 May 2019 at 18:55, David Rowley wrote:
> and an updated patch, rebased after the pgindent run.
>
> Hopefully, this will make the CF bot happy again.
and rebased again due to a conflict with some List changes that
touched ruleutils.c.
I also made another couple of passes over this
On Wed, 24 Apr 2019 at 11:42, David Rowley wrote:
> I've added this to the July commitfest so that I don't forget about it.
>
> https://commitfest.postgresql.org/23/2102/
and an updated patch, rebased after the pgindent run.
Hopefully, this will make the CF bot happy again.
--
David Rowley
On Tue, 23 Apr 2019 at 01:12, David Rowley wrote:
> I started working on this today and I've attached what I have so far.
I've added this to the July commitfest so that I don't forget about it.
https://commitfest.postgresql.org/23/2102/
--
David Rowley
On Fri, 19 Apr 2019 at 05:25, Tom Lane wrote:
> So what I'm thinking is that I made a bad decision in 1cc29fe7c,
> which did this:
>
> ... In passing, simplify the EXPLAIN code by
> having it deal primarily in the PlanState tree rather than separately
> searching Plan and PlanState
On 2019/04/21 15:25, David Rowley wrote:
> On Fri, 19 Apr 2019 at 20:01, Amit Langote
> wrote:
>> Another approach, as I mentioned above, is to extend the hack that begins
>> in nodeAppend.c (and nodeMergeAppend.c) into explain.c, as in the
>> attached. Then:
>>
>> explain verbose select * from
On Fri, 19 Apr 2019 at 20:01, Amit Langote
wrote:
>
> On 2019/04/19 2:25, Tom Lane wrote:
> > Amit Langote writes:
> >> Another idea is to teach explain.c about this special case of run-time
> >> pruning having pruned all child subplans even though appendplans contains
> >> one element to cater
On 2019/04/19 17:00, Amit Langote wrote:
> On 2019/04/19 2:25, Tom Lane wrote:
>> Amit Langote writes:
>>> Another idea is to teach explain.c about this special case of run-time
>>> pruning having pruned all child subplans even though appendplans contains
>>> one element to cater for targetlist
On 2019/04/19 3:13, Robert Haas wrote:
> On Tue, Apr 16, 2019 at 10:49 PM Amit Langote
> wrote:
>> Maybe, not show them? That may be a bit inconsistent, because the point
>> of VERBOSE is to the targetlist among other things, but maybe the users
>> wouldn't mind not seeing it on such empty
On 2019/04/19 2:25, Tom Lane wrote:
> Amit Langote writes:
>> Another idea is to teach explain.c about this special case of run-time
>> pruning having pruned all child subplans even though appendplans contains
>> one element to cater for targetlist accesses. That is, Append will be
>> displayed
I wrote:
> [ let's fix this by reverting ruleutils back to using Plans not PlanStates ]
BTW, while I suspect the above wouldn't be a huge patch, it doesn't
seem trivial either. Since the issue is (a) cosmetic and (b) not new
(v11 behaves the same way), I don't think we should consider it to be
On Tue, Apr 16, 2019 at 10:49 PM Amit Langote
wrote:
> Maybe, not show them? That may be a bit inconsistent, because the point
> of VERBOSE is to the targetlist among other things, but maybe the users
> wouldn't mind not seeing it on such empty Append nodes. OTOH, they are
> more likely to
Amit Langote writes:
> On 2019/04/17 13:10, Tom Lane wrote:
>> No, the larger issue is that *any* plan node above the Append might
>> be recursing down to/through the Append to find out what to print for
>> a Var reference. We have to be able to support that.
> I wonder why the original
On 2019/04/17 13:10, Tom Lane wrote:
> David Rowley writes:
>> On Wed, 17 Apr 2019 at 15:54, Tom Lane wrote:
>>> What I'm more worried about is whether this breaks any internal behavior
>>> of explain.c, as the comment David quoted upthread seems to think.
>>> If we need to have a tlist to
David Rowley writes:
> On Wed, 17 Apr 2019 at 15:54, Tom Lane wrote:
>> What I'm more worried about is whether this breaks any internal behavior
>> of explain.c, as the comment David quoted upthread seems to think.
>> If we need to have a tlist to reference, can we make that code look
>> to the
On 2019/04/17 12:58, David Rowley wrote:
> On Wed, 17 Apr 2019 at 15:54, Tom Lane wrote:
>>
>> Amit Langote writes:
>>> On 2019/04/17 11:29, David Rowley wrote:
Where do you think the output list for EXPLAIN VERBOSE should put the
output column list in this case? On the Append node, or
On Wed, 17 Apr 2019 at 15:54, Tom Lane wrote:
>
> Amit Langote writes:
> > On 2019/04/17 11:29, David Rowley wrote:
> >> Where do you think the output list for EXPLAIN VERBOSE should put the
> >> output column list in this case? On the Append node, or just not show
> >> them?
>
> > Maybe, not
Amit Langote writes:
> On 2019/04/17 11:29, David Rowley wrote:
>> Where do you think the output list for EXPLAIN VERBOSE should put the
>> output column list in this case? On the Append node, or just not show
>> them?
> Maybe, not show them?
Yeah, I think that seems like a reasonable idea. If
On 2019/04/17 11:29, David Rowley wrote:
> On Wed, 17 Apr 2019 at 13:13, Amit Langote
> wrote:
>> When you see this:
>>
>> explain select * from t1 where dt = current_date + 400;
>> QUERY PLAN
>>
>> Append
On Wed, 17 Apr 2019 at 13:13, Amit Langote
wrote:
> When you see this:
>
> explain select * from t1 where dt = current_date + 400;
> QUERY PLAN
>
> Append (cost=0.00..198.42 rows=44 width=8)
>Subplans
Hi,
On 2019/04/16 21:09, David Rowley wrote:
> On Tue, 16 Apr 2019 at 23:55, Yuzuko Hosoya
> wrote:
>> postgres=# explain analyze select * from t1 where dt = current_date + 400;
>> QUERY PLAN
>>
On Tue, 16 Apr 2019 at 23:55, Yuzuko Hosoya wrote:
> postgres=# explain analyze select * from t1 where dt = current_date + 400;
> QUERY PLAN
> ---
> Append
Hi all,
I found a runtime pruning test case which may be a problem as follows:
create table t1 (id int, dt date) partition by range(dt);
create table t1_1 partition of t1 for values from ('2019-01-01') to
('2019-04-01');
create table t1_2 partition of t1 for values from ('2019-04-01') to
37 matches
Mail list logo
