| From: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
|---|---|
| To: | Nikita Glukhov <n(dot)gluhov(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 19:30:38 |
| Message-ID: | CAPpHfdsnNdryJ765=oqw16Nv4fKdHEJ+T5Tm07asOL6a4s3W9g@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Sep 16, 2019 at 3:47 PM Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru> wrote:
> 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.
First patch is minor editing from me and commit message is attached.
I'm going to push it if no objections.
------
Alexander Korotkov
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-v4.patch | application/octet-stream | 23.3 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2019-09-16 19:38:47 | Re: block-level incremental backup |
| Previous Message | Konstantin Knizhnik | 2019-09-16 19:29:18 | Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions |