Re: pruning disabled for array, enum, record, range type partition keys

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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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}';
> ----------------------------------------
> 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.


In response to

Browse pgsql-hackers by date

  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