On Mon, Oct 28, 2019 at 11:11 AM Anastasia Lubennikova <a.lubennik...@postgrespro.ru> wrote: > At first I implemented bitwise as default, because it is more common . > Though, I agree that it's essential to avoid false positives here. > The new version of the patch is attached. I also updated pg_dump. > > A few more open questions: > 1) How to handle contrib modules that create new opclasses? > Since default is 'not bitwise' it means that various operator classes > created in extensions > such as bloom, btree_gin and others, won't be able to take advantage of > various optimizations > that require the opclass to be BITWISE.
What optimizations? Do we anticipate that other index AMs will benefit from BITWISE-ness? > 'v2-Opclass-bitwise-equality-0002' patch simply adds BITWISE keyword > where necessary. > > 2) Whether we should provide ALTER OPERATOR CLASS SET BITWISE syntax? I think that that's probably not desirable. There should at least be a strong practical advantage if we go that way. This would mean ALTER OPERATOR CLASS could change the "substance" of an opclass, which is fundamentally different from what it can do already (it currently just changes the owner, or the schema that it is stored in). > 3) Current patch modifies regression test so that it checks CREATE > OPCLASS BITWISE syntax. > Is there anything else worth testing? As I see it, this patch is just > about infrastructure changes, > and more specific tests will be added by features that will implement > further optimizations. I think so too -- this is really about associating a single piece of information with an operator class. BTW: No need to bump catversion when posting a patch, which I see in "v2-Opclass-*0001.patch". That is our policy. (A catversion bump is generally supposed to be done at the last minute, just as the patch is committed. This avoids unnecessary conflicts against the master branch over time, as a patch is developed.) -- Peter Geoghegan
