From: | Nathan Boley <npboley(at)gmail(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: plpgsql arrays |
Date: | 2009-04-03 19:03:43 |
Message-ID: | 6fa3b6e20904031203m3867d02cnbc599c14b123d961@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
> Uh, no, it wouldn't. Visually:
>
> L1 -------------------------
> L2 -----------
> L3 ---------------------
>
> R1 --------
>
> At L2, you'd conclude that you're done matching R1.
>
No, you should conclude that you're done matching L2. You conclude
you're done matching R1 when you reach L4 ( or there exists a j st
Lj.start > R1.end, or equivalently Lj is strictly greater than R1 )
FWIW, this is a very common problem in bioinformatics. I've mostly
implemented this in python and C. The code is available at
encodestatistics.org. Look in encode.py at the overlap method of the
feature_region class, or ( for the C version ) region_overlap in
block_bootstrap.c ( svn is more up to date for the C ).
-Nathan
From | Date | Subject | |
---|---|---|---|
Next Message | David Kerr | 2009-04-03 19:53:02 | Question on pgbench output |
Previous Message | Tom Lane | 2009-04-03 17:38:53 | Re: plpgsql arrays |