| 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: | Whole Thread | Raw Message | 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 |