From: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
---|---|
To: | Matthew Wakeling <matthew(at)flymine(dot)org> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Very specialised query |
Date: | 2009-03-27 20:07:56 |
Message-ID: | 945DB222-5D3B-466A-80D1-50563B12A407@hi-media.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Hi,
Le 26 mars 09 à 15:30, Matthew Wakeling a écrit :
> Now, it happens that there is an algorithm for calculating overlaps
> which is really quick. It involves iterating through the table in
> order of the start variable and keeping a list of ranges which
> "haven't ended yet". When you read the next range from the table,
> you firstly purge all the ranges from the list that end before the
> beginning of the new range. Then, you output a result row for each
> element in the list combined with the new range, then you add the
> new range to the list.
>
> This algorithm just doesn't seem to fit into SQL at all.
Maybe it's just that I didn't devote enough time to reading your
detailed explanation above, but this part sounds like it could be done
in an aggregate you'd use in a correlated subquery containing the
right ORDER BY, couldn't it?
http://www.postgresql.org/docs/8.3/interactive/sql-createaggregate.html
HTH,
--
dim
From | Date | Subject | |
---|---|---|---|
Next Message | David Rees | 2009-03-27 20:33:18 | Re: I have a fusion IO drive available for testing |
Previous Message | Tom Lane | 2009-03-27 18:43:13 | Re: Very specialised query |