On 2018/04/09 19:14, Amit Langote wrote:
> 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.
Added to the open items list.
https://wiki.postgresql.org/wiki/PostgreSQL_11_Open_Items#Open_Issues
Thanks,
Amit