| 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 |
| Thread: | |
| 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 https://www.2ndQuadrant.com/
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 |
| 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 |