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

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pruning disabled for array, enum, record, range type partition keys
Date: 2018-04-17 22:11:18
Message-ID: 20180417221118.6jxa42h3k37eof6d@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Amit Langote wrote:

> Ah, I think I got it after staring at the (btree) index code for a bit.
> What pruning code got wrong is that it's comparing the expression type
> (type of the constant arg that will be compared with partition bound
> datums when pruning) with the partopcintype to determine if we should look
> up the cross-type comparison/hashing procedure, whereas what the latter
> should be compare with is the clause operator's oprighttype. ISTM, if
> op_in_opfamily() passed for the operator, that's the correct thing to do.

I wonder why you left out the hash partitioning case? I don't really
know that this is correct, but here's a delta patch as demonstration.

(v3 is your patch, I think the only change is I renamed the tables used
in the test)

Álvaro Herrera
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment Content-Type Size
compfuncs-delta.patch text/plain 3.9 KB
v3-0001-Fix-pruning-code-to-determine-comparison-function.patch text/plain 8.5 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2018-04-17 22:38:14 Re: [sqlsmith] Unpinning error in parallel worker
Previous Message Bruce Momjian 2018-04-17 21:49:42 Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS