Re: Confusing EXPLAIN output in case of inherited tables

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>
Cc: Robert Haas <robertmhaas@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2012-09-21T17:12:09Z
Lists: pgsql-hackers

Attachments

I wrote:
> ... In the attached I've hacked around this by causing the planner to
> assign new aliases to RTEs that it replaces in this way (see planagg.c
> and prepunion.c diffs).  This seems like a bit of a kluge, but it
> doesn't take much code.  An alternative that I'm considering is to
> have EXPLAIN make a pre-pass over the plan tree to identify which
> RTEs will actually be referenced, and then consider only those RTEs
> while assigning aliases.  This would be a great deal more code though,
> and code which would require maintenance every time we add plan node
> types etc.  So I'm not sure it's really a better answer.  Thoughts?

Attached is a second draft that does it like that.  This adds about 130
lines to explain.c compared to the other way, but on reflection it's
probably a better solution compared to trying to kluge things in the
planner.  The change in the select_views results shows that there's
at least one other case of duplicated RTE names that I'd not covered
with the two planner kluges.

I think the next question is whether we want to back-patch this.
Although the problem with incorrect view dumping is arguably a data
integrity issue (cf bug #7553), few enough people have hit it that
I'm not sure it's worth taking risks for.  I'd feel better about
this code once it'd got through a beta test cycle.  Comments?

			regards, tom lane