Skip site navigation (1) Skip section navigation (2)

Re: EXPLAIN doesn't show sufficient info for wCTE cases

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: EXPLAIN doesn't show sufficient info for wCTE cases
Date: 2011-02-28 16:44:06
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Mon, Feb 28, 2011 at 11:39 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> EXPLAIN currently shows ModifyTable nodes as just "Insert", "Update",
> or "Delete", without any indication of the target table.  This was
> more or less good enough when there could only be one such node per
> query, but it's looking pretty inadequate to me as I play around
> with data-modifying statements in WITH.
> The obvious thing to do is show the target table much as we do for
> table scan nodes, eg "Update on my_table".  There is a deficiency
> in that, which is that for inherited UPDATE/DELETE cases a single
> ModifyTable node could have multiple target tables.  But after
> reflecting on it a bit, I think it would be good enough to show
> the parent table name.  The individual child plans will necessarily
> include scans of the individual child tables, so you can figure
> out which is which from that if you need to know.
> Alternatively we could list all the target tables in a new node
> attribute, eg
>        Update (costs...)
>                Target Tables: foo_parent, foo_child1, ...
> But in the majority of cases this seems like a waste of precious
> vertical space.
> Thoughts?

I think it's good to include the table name, for sure.  I *think* I
agree that it isn't necessary to include the child names.

Robert Haas
The Enterprise PostgreSQL Company

In response to


pgsql-hackers by date

Next:From: Peter EisentrautDate: 2011-02-28 16:52:31
Subject: Re: pl/python custom exceptions for SPI
Previous:From: Tom LaneDate: 2011-02-28 16:39:17
Subject: EXPLAIN doesn't show sufficient info for wCTE cases

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group