Re: Better management of mergejoinable operators

Поиск
Список
Период
Сортировка
От Andrew - Supernews
Тема Re: Better management of mergejoinable operators
Дата
Msg-id slrnenv4gq.1aj7.andrew+nonews@atlantis.supernews.net
обсуждение исходный текст
Ответ на Better management of mergejoinable operators  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Better management of mergejoinable operators  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 2006-12-13, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
>>>> Right offhand I cannot see a reason why there should be different
>>>> equality operators with the same sortops.  (If anyone can come up with
>>>> a plausible scenario for that, stop me here...)
>
> BTW, I think it's possible to prove that there need never be two for the
> case of both sides the same datatype.  If we have a sortop "A < B" on a
> single datatype, then its commutator is well defined: "A > B" if and
> only if "B < A".  And by the trichotomy law, "A = B" must be true in
> exactly those cases for which neither "A < B" nor "A > B".  So there is
> only one possible behavior for an equality operator that is consistent
> with the sortop.

Counterexample even for a single data type: define an operator x =* y
which is true when 2x = y.  This is mergejoinable using the following
operators: SORT1 = <, SORT2 = <, LTCMP = (2x < y), RTCMP = (2x > y)
(which is of course the same sortops as for regular =).

The LTCMP and GTCMP operators imply a unique join operator due to
trichotomy, but this is not true for the sortops. While the above is
a bit contrived, I think non-contrived examples could be found too.

-- 
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services


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

Предыдущее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: Grouped Index Tuples
Следующее
От: Tom Lane
Дата:
Сообщение: Re: LOCK_DEBUG breaks compile in 8.2 (and possibly later)