From: | "Shridhar Daithankar" <shridhar_daithankar(at)persistent(dot)co(dot)in> |
---|---|
To: | PgSQL Performance ML <pgsql-performance(at)postgresql(dot)org>, pgsql-sql(at)postgresql(dot)org |
Subject: | Re: [SQL] EXTERNAL storage and substring on long strings |
Date: | 2003-08-04 16:19:15 |
Message-ID: | 3F2ED4DB.30291.5A1A19@localhost |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance pgsql-sql |
On 4 Aug 2003 at 12:14, Scott Cain wrote:
> I forgot about searching--I suspect that application is why I faced
> opposition for shredding in my schema development group. Maybe I should
> push that off to the file system and use grep (or BLAST). Otherwise, I
> could write a function that would search the chunks first, then after
> failing to find the substring in those, I could start sewing the chunks
> together to look for the query string. That could get ugly (and
> slow--but if the user knows that and expects it to be slow, I'm ok with
> that).
I assume your DNA sequence is compacted. Your best bet would be to fetch them
from database and run blast on them in client memory. No point duplicating
blast functionality. Last I tried it beat every technique of text searching
when heuristics are involved.
Bye
Shridhar
--
There are two types of Linux developers - those who can spell, andthose who
can't. There is a constant pitched battle between the two.(From one of the post-
1.1.54 kernel update messages posted to c.o.l.a)
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Cain | 2003-08-04 16:25:41 | Re: [SQL] EXTERNAL storage and substring on long strings |
Previous Message | Scott Cain | 2003-08-04 16:14:06 | Re: [SQL] EXTERNAL storage and substring on long strings |
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Cain | 2003-08-04 16:25:41 | Re: [SQL] EXTERNAL storage and substring on long strings |
Previous Message | Scott Cain | 2003-08-04 16:14:06 | Re: [SQL] EXTERNAL storage and substring on long strings |