Re: Better management of mergejoinable operators

Поиск
Список
Период
Сортировка
От Andrew - Supernews
Тема Re: Better management of mergejoinable operators
Дата
Msg-id slrnenv8fh.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:
> Andrew - Supernews <andrew+nonews@supernews.com> writes:
>> On 2006-12-13, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> BTW, I think it's possible to prove that there need never be two for the
>>> case of both sides the same datatype.
>
>> 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 =).
>
> I think not --- the corresponding sort operators would have to be
> "2x < y" etc, else the trichotomy law fails, and so do all standard
> sort algorithms.

No, because if x < x' then 2x < 2x'.  Or to put it another way, doing
a merge join on (2x = y) simply requires matching the sorted lists of
x's and y's against each other in a different place, rather than changing
the sort order of either.

You're suffering from a fundamental confusion between the ltcmp/rtcmp
operators (which indeed must be trichotomous with the join operator)
and the sort operators.

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


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

Предыдущее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: Load distributed checkpoint
Следующее
От: "Albe Laurenz"
Дата:
Сообщение: Re: psql commandline conninfo