pruning disabled for array, enum, record, range type partition keys
От | Amit Langote |
---|---|
Тема | pruning disabled for array, enum, record, range type partition keys |
Дата | |
Msg-id | 2b02f1e9-9812-9c41-972d-517bdc0f815d@lab.ntt.co.jp обсуждение исходный текст |
Ответы |
Re: pruning disabled for array, enum, record, range type partitionkeys
Re: pruning disabled for array, enum, record, range type partition keys |
Список | pgsql-hackers |
Hi. I noticed that the newly added pruning does not work if the partition key is of one of the types that have a corresponding pseudo-type. -- array type list partition key create table arrpart (a int[]) partition by list (a); create table arrpart1 partition of arrpart for values in ('{1}'); create table arrpart2 partition of arrpart for values in ('{2, 3}', '{4, 5}'); explain (costs off) select * from arrpart where a = '{1}'; QUERY PLAN ---------------------------------------- Append -> Seq Scan on arrpart1 Filter: (a = '{1}'::integer[]) -> Seq Scan on arrpart2 Filter: (a = '{1}'::integer[]) (5 rows) For pruning, we normally rely on the type's operator class information in the system catalogs to be up-to-date, which if it isn't we give up on pruning. For example, if pg_amproc entry for a given type and AM type (btree, hash, etc.) has not been populated, we may fail to prune using a clause that contains an expression of the said type. While this is the theory for the normal cases, we should make an exception for the pseudo-type types. For those types, we never have pg_amproc entries with the "real" type listed. Instead, the pg_amproc entries contain the corresponding pseudo-type. For example, there aren't pg_amproc entries with int4[] (really, its OID) as amproclefttype and/or amprocrighttype, instead anyarray is listed there. Attached find a patch that tries to fix that and adds relevant tests. Thanks, Amit
Вложения
В списке pgsql-hackers по дате отправления: