Re: Display of multi-target-table Modify plan nodes in EXPLAIN

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Display of multi-target-table Modify plan nodes in EXPLAIN
Date: 2015-03-23 06:38:03
Message-ID: 550FB4CB.3070408@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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)
> ]
> [
> Update Target: ft1
> Remote SQL: UPDATE ref1 ...
> Plan: (foreign scan on ft1 here)
> ]
> [
> Update Target: ft2
> Remote SQL: UPDATE ref2 ...
> Plan: (foreign scan on ft2 here)
> ]
> [
> Update Target: child3
> Plan: (seq scan on child3 here)
> ]

The "Remote SQL" nodes should go under the Foreign Scan nodes.

> but I think that ship has sailed. Changing the logical structure of
> EXPLAIN output like this would break clients that know what's where in
> JSON/YAML/XML formats, which is exactly what we said we wouldn't do with
> those output formats.

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 the output for humans, so let's do what makes most
sense for humans. Admin tools will have to deal with new node types, and
also new plan structures in every new release anyway. And if an admin
tool doesn't recognize the new format, it surely falls back to
displaying them in some a reasonable generic form.

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2015-03-23 06:49:15 Re: Zero-padding and zero-masking fixes for to_char(float)
Previous Message Ashutosh Bapat 2015-03-23 06:01:07 Re: inherit support for foreign tables