От: Matthew Wakeling
Тема: Re: plpgsql arrays
Дата: ,
Msg-id: alpine.DEB.2.00.0904031507000.21772@aragorn.flymine.org
(см: обсуждение, исходный текст)
Ответ на: Re: plpgsql arrays  (Tom Lane)
Ответы: Re: plpgsql arrays  (Tom Lane)
Список: pgsql-performance

Скрыть дерево обсуждения

plpgsql arrays  (Matthew Wakeling, )
 Re: plpgsql arrays  (Robert Haas, )
  Re: plpgsql arrays  (Matthew Wakeling, )
   Re: plpgsql arrays  (Tom Lane, )
    Re: plpgsql arrays  (Matthew Wakeling, )
     Re: plpgsql arrays  (Tom Lane, )
      Re: plpgsql arrays  (Matthew Wakeling, )
       Re: plpgsql arrays  (Matthew Wakeling, )
       Re: plpgsql arrays  (Tom Lane, )
        Re: plpgsql arrays  (Matthew Wakeling, )
        Re: plpgsql arrays  (Nathan Boley, )
    Re: plpgsql arrays  (Simon Riggs, )
     Re: plpgsql arrays  (Alvaro Herrera, )
     Re: plpgsql arrays  (Tom Lane, )
      Re: plpgsql arrays  (Matthew Wakeling, )
     Re: plpgsql arrays  (Matthew Wakeling, )
      Re: plpgsql arrays  (Robert Haas, )
 Re: plpgsql arrays  (Tom Lane, )
  Re: plpgsql arrays  (Matthew Wakeling, )
   Re: plpgsql arrays  (justin, )
    Re: plpgsql arrays  (Matthew Wakeling, )
     Re: plpgsql arrays  (justin, )
     Re: plpgsql arrays  (Tom Lane, )
      Re: plpgsql arrays  (Matthew Wakeling, )
   Re: plpgsql arrays  (Merlin Moncure, )
    Re: plpgsql arrays  (Tom Lane, )
     Re: plpgsql arrays  (Matthew Wakeling, )
      Re: plpgsql arrays  (Tom Lane, )
 Re: plpgsql arrays  (Merlin Moncure, )
  Re: plpgsql arrays  (Merlin Moncure, )
   Re: plpgsql arrays  (Matthew Wakeling, )
    Re: plpgsql arrays  (Merlin Moncure, )

On Fri, 3 Apr 2009, Tom Lane wrote:
>> Oh, hang on, I think I saw something in the docs about what conditions can
>> be used in a merge...
>
> No, you got it right the first time.  I was about to suggest that maybe
> you could make it work by recasting the problem as equality on an
> interval datatype, but the problem is that this is not equality but
> "overlaps".  And you can't cheat and call it equality, because it's
> not transitive.

Well, according to
http://www.postgresql.org/docs/8.3/interactive/xoper-optimization.html#AEN41844

| So, both data types must be capable of being fully ordered, and the
| join operator must be one that can only succeed for pairs of values that
| fall at the "same place" in the sort order.

> I don't actually believe that a standard merge join algorithm will work
> with an intransitive join condition ...

A standard merge join should work absolutely fine, depending on how it's
implemented. If the implementation keeps a list of "current" right-hand
elements, and adds right-hand rows to the list when they compare "equal"
to the current left-hand element, and removes them from the list when they
compare "not equal" to the current left-hand element, then it would work
fine. If it does something else like rewinding the right-hand stream, or
throwing away the list when the current left-hand element is "not equal"
the previous left-hand element, (which would be fine for true equality)
then it will not work.

The description in the docs doesn't make it clear which way Postgres does
it.

Matthew

--
 I have an inferiority complex. But it's not a very good one.


В списке pgsql-performance по дате сообщения:

От: David Kerr
Дата:
Сообщение: Question on pgbench output
От: Tom Lane
Дата:
Сообщение: Re: Question on pgbench output