Re: [HACKERS] path toward faster partition pruning - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: [HACKERS] path toward faster partition pruning
Date
Msg-id 20180508220546.kfjoz77aoee3wowv@alvherre.pgsql
Whole thread Raw
In response to Re: [HACKERS] path toward faster partition pruning  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: [HACKERS] path toward faster partition pruning
Re: [HACKERS] path toward faster partition pruning
List pgsql-hackers
So I found that this query also crashed (using your rig),

create table coercepart (a varchar) partition by list (a);
create table coercepart_ab partition of coercepart for values in ('ab');
create table coercepart_bc partition of coercepart for values in ('bc');
create table coercepart_cd partition of coercepart for values in ('cd');
explain (costs off) select * from coercepart where a ~ any ('{ab}');

The reason for this crash is that gen_partprune_steps_internal() is
unable to generate any steps for the clause -- which is natural, since
the operator is not in a btree opclass.  There are various callers
of gen_partprune_steps_internal that are aware that it could return an
empty set of steps, but this one in match_clause_to_partition_key for
the ScalarArrayOpExpr case was being a bit too optimistic.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment

pgsql-hackers by date:

Previous
From: "Tels"
Date:
Subject: Re: perlcritic script
Next
From: Craig Ringer
Date:
Subject: Re: Setting libpq TCP keepalive parameters from environment