[HACKERS] scan on inheritance parent with no children in current session

Hi All,
Consider a parent table which has no child in the current session, but
has temporary children in other sessions.

Session 1
postgres=# create table parent (a int);
CREATE TABLE

Session 2:
postgres=# create temp table temp_child () inherits(parent);
CREATE TABLE

Before commit d3cc37f1d801a6b5cad9bf179274a8d767f1ee50. We would have
Seq Scan plan for scanning parent in session 1
postgres=# explain verbose select * from parent;
                         QUERY PLAN
-------------------------------------------------------------
 Seq Scan on public.parent  (cost=0.00..0.00 rows=1 width=4)
   Output: parent.a
(2 rows)

In session 2, it would be an Append plan
postgres=# explain verbose select * from parent;
                                  QUERY PLAN
------------------------------------------------------------------------------
 Append  (cost=0.00..35.50 rows=2551 width=4)
   ->  Seq Scan on public.parent  (cost=0.00..0.00 rows=1 width=4)
         Output: parent.a
   ->  Seq Scan on pg_temp_4.temp_child  (cost=0.00..35.50 rows=2550 width=4)
         Output: temp_child.a
(5 rows)

After that commit in session 1, we get an Append plan
postgres=# explain verbose select * from parent;
                            QUERY PLAN
-------------------------------------------------------------------
 Append  (cost=0.00..0.00 rows=1 width=4)
   ->  Seq Scan on public.parent  (cost=0.00..0.00 rows=1 width=4)
         Output: parent.a
(3 rows)

I don't think this is an intentional change. Here's patch to fix it.
The comment in the patch uses term "real child" in the context of
comments about temporary children from other session and the comment
at the end of the function where rte->inh is reset. May be we should
move the second comment before setting has_child in the patch and use
"real child" in the comment at the end to avoid repetition. But I want
to first check whether we want this fix or we can live with the Append
plan.

-- 
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers