From: | Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru> |
---|---|
To: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Subject: | Re: Bug in GiST paring heap comparator |
Date: | 2019-09-16 12:44:07 |
Message-ID: | 907ff6e7-001c-8e86-e05f-ffe5483c2634@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 13.09.2019 20:17, Alexander Korotkov wrote:
> On Fri, Sep 13, 2019 at 5:23 PM Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru> wrote:
>> I have moved handling of NULL ordering keys from opclasses to the common
>> SP-GiST code, but really I don't like how it is implemented now. Maybe it's
>> worth to move handling of NULL order-by keys to the even more higher
>> level so,
>> that AM don't have to worry about NULLs?
> Yes, optimizer could remove away "col op NULL" clauses from ORDER BY
> if op is strict operator. And then such clauses wouldn't be passed to
> AM. But I see this as future improvement. For backpatching we should
> solve this at AM side.
>
>> Also I leaved usages of IndexOrderByDistance in opclasses. I think, that
>> may help to minimize opclass changes in the future.
> Could you please extract this as a separate patch. We can consider
> this for master, but we shouldn't backpatch this.
Propagation of IndexOrderByDistance in SP-GiST was extracted into a separate
patch #2.
--
Nikita Glukhov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Attachment | Content-Type | Size |
---|---|---|
0001-Fix-GiST-and-SP-GiST-ordering-by-distance-for-NULLs-v3.patch | text/x-patch | 23.0 KB |
0002-Use-IndexOrderByDistance-in-SP-GiST-user-functions-v3.patch | text/x-patch | 13.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Arseny Sher | 2019-09-16 13:24:19 | Re: (Re)building index using itself or another index of the same table |
Previous Message | Amit Kapila | 2019-09-16 12:28:43 | Re: range test for hash index? |