Re: plpgsql arrays

From: Matthew Wakeling
Subject: Re: plpgsql arrays
Date: ,
Msg-id: alpine.DEB.2.00.0904031507000.21772@aragorn.flymine.org
(view: Whole thread, Raw)
In response to: Re: plpgsql arrays  (Tom Lane)
Responses: Re: plpgsql arrays  (Tom Lane)
List: pgsql-performance

Tree view

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 by date:

From: David Kerr
Date:
Subject: Question on pgbench output
From: Tom Lane
Date:
Subject: Re: Question on pgbench output