Re: [HACKERS] Declarative partitioning vs. sql_inheritance
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] Declarative partitioning vs. sql_inheritance |
Дата | |
Msg-id | CA+TgmoYe+EG7LdYX6pkcNxr4ygkP4+A=jm9o-CPXyOvRiCNwaQ@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: [HACKERS] Declarative partitioning vs. sql_inheritance
Re: [HACKERS] Declarative partitioning vs. sql_inheritance Re: [HACKERS] Declarative partitioning vs. sql_inheritance Re: [HACKERS] Declarative partitioning vs. sql_inheritance |
Список | pgsql-hackers |
On Thu, Dec 15, 2016 at 10:40 AM, Dmitry Ivanov <d.ivanov@postgrespro.ru> wrote: > Hi everyone, > > Looks like "sql_inheritance" GUC is affecting partitioned tables: > > explain (costs off) select * from test; > QUERY PLAN ------------------------------ > Append > -> Seq Scan on test > -> Seq Scan on test_1 > -> Seq Scan on test_2 > -> Seq Scan on test_1_1 > -> Seq Scan on test_1_2 > -> Seq Scan on test_1_1_1 > -> Seq Scan on test_1_2_1 > (8 rows) > > > set sql_inheritance = off; > > > explain (costs off) select * from test; > QUERY PLAN ------------------ > Seq Scan on test > (1 row) > > > I might be wrong, but IMO this should not happen. Queries involving update, > delete etc on partitioned tables are basically broken. Moreover, there's no > point in performing such operations on a parent table that's supposed to be > empty at all times. An earlier version of Amit's patches tried to handle this by forcing sql_inheritance on for partitioned tables, but it wasn't well-implemented and I don't see the point anyway. Sure, turning off sql_inheritance off for partitioned tables produces stupid results. But turning off sql_inheritance for inheritance hierarchies also produces stupid results. If we were going to do anything about this, my vote would be to remove sql_inheritance. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: