14.11.2019 0:25, Peter Geoghegan wrote:
> On Mon, Oct 28, 2019 at 11:11 AM Anastasia Lubennikova
> <a.lubennikova@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?
I was thinking of possible planner optimizations, that Tom mentioned up
thread.
Though, I don't have any specific examples. Anyway, we can implement
support for user-defined opclasses later.
>> 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.
Great. It seems that the patch is ready for commit.
I attached new version with pg_opclass documentation update.
One more thing I am uncertain about is array_ops. Arrays may contain
bitwise and not bitwise element types.
What is the correct value of opcisbitwise the array_ops itself?
--
Anastasia Lubennikova
Postgres Professional:http://www.postgrespro.com
The Russian Postgres Company
