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
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=# explain (verbose) update pt1 set c1=c1+1;
10 matches
Mail list logo