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
