Re: Building infrastructure for B-Tree deduplication that recognizeswhen opclass equality is also equivalence

Поиск
Список
Период
Сортировка
От Anastasia Lubennikova
Тема Re: Building infrastructure for B-Tree deduplication that recognizeswhen opclass equality is also equivalence
Дата
Msg-id d8d75df3-4c41-ce13-6174-5f14b35e6f5a@postgrespro.ru
обсуждение исходный текст
Ответ на Re: Building infrastructure for B-Tree deduplication that recognizeswhen opclass equality is also equivalence  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Building infrastructure for B-Tree deduplication that recognizeswhen opclass equality is also equivalence  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
29.12.2019 2:56, Robert Haas wrote:
> On Tue, Dec 24, 2019 at 7:29 AM Anastasia Lubennikova
> <a.lubennikova@postgrespro.ru> wrote:
>> We can make this 'opcisbitwise' parameter enum (or char) instead of
>> boolean to mark
>> "always bitwise", "never bitwise" and "maybe bitwise". Though, I doubt
>> if it will be helpful in any real use case.
> What would be the difference between "never bitwise" and "maybe
> bitwise" in that scheme?

In this design "maybe" category reflects the need for an extra recheck.

For example, float and numeric types are "never bitwise equal", while array,
text, and other container types are "maybe bitwise equal". An array of 
integers
or text with C collation can be treated as bitwise equal attributes, and it
would be too harsh to restrict them from deduplication.

What bothers me is that this option will unlikely be helpful on its own 
and we
should also provide some kind of recheck function along with opclass, which
complicates this idea even further and doesn't seem very clear.

-- 
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Justin Pryzby
Дата:
Сообщение: Re: comment regarding double timestamps; and, infinite timestampsand NaN
Следующее
От: Philippe BEAUDOIN
Дата:
Сообщение: Re: proposal: schema variables