From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Matthew Wakeling <matthew(at)flymine(dot)org> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: plpgsql arrays |
Date: | 2009-04-03 14:48:31 |
Message-ID: | 1138.1238770111@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Matthew Wakeling <matthew(at)flymine(dot)org> writes:
> On Fri, 3 Apr 2009, Tom Lane wrote:
>> Not unless you have sorted the inputs in some way that has more
>> knowledge than the "equal" operator represents. Otherwise you can have
>> elements drop out that might still be needed to match to a later
>> left-hand element.
> Of course. You certainly have to choose a sort order that works. Sorting
> by the start field would be sufficient in this case.
Uh, no, it wouldn't. Visually:
L1 -------------------------
L2 -----------
L3 ---------------------
R1 --------
At L2, you'd conclude that you're done matching R1.
Intuitively, it seems like 1-D "overlaps" is a tractable enough
operator that you should be able to make something merge-like
work. But it's more complicated than I think you realize.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Matthew Wakeling | 2009-04-03 14:58:03 | Re: plpgsql arrays |
Previous Message | Matthew Wakeling | 2009-04-03 14:45:25 | Re: plpgsql arrays |