Re: [PATCH] kNN for btree

From: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
To: Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>
Cc: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] kNN for btree
Date: 2018-12-29 22:19:50
Message-ID: CAPpHfdstf812dYObwMeu54P5HijHgURNdoJRc3jKxRj2LsQJRg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Dec 27, 2018 at 5:46 AM Alexander Korotkov
<a(dot)korotkov(at)postgrespro(dot)ru> wrote:
> * 0006-Remove-distance-operators-from-btree_gist-v04.patch
>
> I see you provide btree_gist--1.6.sql and remove btree_gist--1.2.sql.
> Note, that in order to better checking of extension migrations, we're
> now providing just migration script to new version. So, everybody
> installing new version will go through the migration. However, in
> this particular case we've mass deletion of former extension objects.
> So, I think this case should be an exception to the rules. And it's
> good to provide new version of extension script in this case. Other
> opinions?

I also note that you've removed implementation of distance functions
from btree_gist. But during pg_upgrade extensions are moved "as is".
Not just CREATE EXTENSION command is dumped, but the whole extension
content. pg_upgrade'd instances would have old version of extension
metadata with new .so until ALTER EXTENSION UPDATE. So, user would get
errors about missed function in .so until updates the extension.

We're typically evade this by inclusion of old functions into new .so.
Then user can work normally before extension update. In this
particular case, we can leave the distance functions in the .so, but
make them just wrappers over core functions.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2018-12-29 22:19:58 Re: WIP: Avoid creation of the free space map for small tables
Previous Message John Naylor 2018-12-29 21:59:52 Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)