On Mon, Mar 23, 2015 at 8:00 PM, Tom Lane wrote:
> Ashutosh Bapat writes:
> > On Mon, Mar 23, 2015 at 10:51 AM, Tom Lane wrote:
> >> Hm? We don't have scan nodes that read more than one table, so I'm
> >> not following your point.
>
> > But in the text output you gave
> > Update on public.pt1
On Mon, Mar 23, 2015 at 10:26 AM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> On 03/22/2015 03:02 AM, Tom Lane wrote:
>>> In a green field we might choose to solve this by refactoring the output
>>> so that it's logically ...
>>> but I think that ship has sailed. Changing the logical structu
Ashutosh Bapat writes:
> On Mon, Mar 23, 2015 at 10:51 AM, Tom Lane wrote:
>> Hm? We don't have scan nodes that read more than one table, so I'm
>> not following your point.
> But in the text output you gave
> Update on public.pt1 (cost=0.00..321.05 rows=3541 width=46)
>Update on public.pt
Heikki Linnakangas writes:
> On 03/22/2015 03:02 AM, Tom Lane wrote:
>> In a green field we might choose to solve this by refactoring the output
>> so that it's logically ...
>> but I think that ship has sailed. Changing the logical structure of
>> EXPLAIN output like this would break clients tha
On Sun, Mar 22, 2015 at 11:38 PM, Heikki Linnakangas wrote:
> If we have promised that, I think we should break the promise. No
> application should depend on the details of EXPLAIN output, even if it's in
> JSON/YAML/XML format. EXPLAIN is used by humans, and by tools like pgAdmin
> that display
On 03/22/2015 03:02 AM, Tom Lane wrote:
In a green field we might choose to solve this by refactoring the output
so that it's logically
Multi-Table Update
[
Update Target: pt1
Plan: (seq scan on pt1 here)
]
On Mon, Mar 23, 2015 at 10:51 AM, Tom Lane wrote:
> Ashutosh Bapat writes:
> > On Sun, Mar 22, 2015 at 6:32 AM, Tom Lane wrote:
> >> What I'm imagining instead is that when there's more than one
> >> target relation, we produce output like ...
>
> > This looks better.
> > In the format above, y
Ashutosh Bapat writes:
> On Sun, Mar 22, 2015 at 6:32 AM, Tom Lane wrote:
>> What I'm imagining instead is that when there's more than one
>> target relation, we produce output like ...
> This looks better.
> In the format above, you have specified both the Remote SQL for scan as
> well as updat
On Sun, Mar 22, 2015 at 6:32 AM, Tom Lane wrote:
> I've gotten the foreign table inheritance patch to a state where I'm
> almost ready to commit it, but there's one thing that's bothering me,
> which is what it does for EXPLAIN. As it stands you might get something
> like
>
> regression=# explai