From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pruning disabled for array, enum, record, range type partition keys |
Date: | 2018-04-09 10:17:55 |
Message-ID: | 3dd277f7-a9d9-e563-5cf3-f5df48221e5b@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro HORIGUCHI | 2018-04-09 10:19:32 | Re: Optimizing nested ConvertRowtypeExpr execution |
Previous Message | Etsuro Fujita | 2018-04-09 10:15:28 | Re: postgres_fdw: perform UPDATE/DELETE .. RETURNING on a join directly |