Re: no partition pruning when partitioning using array type

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: no partition pruning when partitioning using array type
Date: 2018-02-01 09:42:40
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 2017/12/11 14:31, Amit Langote wrote:
> On 2017/12/09 3:46, Robert Haas wrote:
>> On Fri, Dec 8, 2017 at 5:40 AM, Amit Langote wrote:
>>> I noticed that if you partition using a array type column, partition
>>> pruning using constraint exclusion fails to work due to a minor problem.
>> I guess the question is whether that's guaranteed to be safe. I spent
>> a little bit of time thinking about it and I don't see a problem. The
>> function is careful to check that the opclasses and collations of the
>> OpExprs are compatible, and it is the behavior of the operator that is
>> in question here, not the column type, so your change seems OK to me.
>> But I hope somebody else will also study this, because this stuff is
>> fairly subtle and I would not like to be the one who breaks it.
> Thanks for taking a look at it.
> I will try to say a little more on why it seems safe. RelabelType node
> exists (if any) on top of a given expression node only to denote that the
> operator for which the node is an input will interpret its result as of
> the type RelableType.resulttype, instead of the node's original type. No
> conversion of values actually occurs before making any decisions that this
> function is in charge of making, because the mismatching types in question
> are known to be binary coercible. Or more to the point, the operator that
> will be used in the proof will give correct answers for the values without
> having to do any conversion of values. IOW, it's okay if we simply drop
> the RelabelType, because it doesn't alter in any way the result of the
> proof that operator_predicate_proof() performs.
> That said, I've to come think in this particular case that the
> partitioning code that generates the predicate expression should be a bit
> smarter about the various types it manipulates such that RelabelType won't
> be added in the first place. In contrast, make_op(), that generates an
> OpExpr from the parser representation of a = '{1}' appearing in the
> query's WHERE clause, won't add the RelabelType because the underlying
> type machinery that it invokes is able to conclude that that's
> unnecessary. The original patch may still be worth considering as a
> solution though.
> I hope someone else chimes in as well. :)

Bug #15042 [1] seems to be caused by this same problem. There, a
RelabelType node is being slapped (by the partitioning code) on a Var node
of a partition key on enum.

Attached updated patch.



Attachment Content-Type Size
v2-0001-Teach-operator_predicate_proof-to-strip-RelabelTy.patch text/plain 5.1 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Christoph Berg 2018-02-01 10:08:39 Re: [HACKERS] GnuTLS support
Previous Message Emre Hasegeli 2018-02-01 09:36:41 Re: [HACKERS] [PATCH] Improve geometric types