Re: [sqlite] SQLite full text speed

2008-04-30 Thread John Stanton
Run a trial, but I am sure that fgrep will be faster.

Scott Baker wrote:
> I'm curious about the speed trade off between a full table scan and just a 
> flat file search... Say I have a database with 2 records in it. If I do 
> a query like:
> 
> SELECT foo FROM table WHERE bar LIKE '%glaven%';
> 
> That will be a full text scan across the table. Would that be any faster 
> than just a regexp against a flat text file? Obviously you get the 
> advantages of SQL were it in a DB, versus a flat file. What other trade 
> offs are there?
> 
> My experience the above, is that in SQLITE it's still incredibly fast.
> 

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] SQLite full text speed

2008-04-29 Thread P Kishor
On 4/29/08, Scott Baker <[EMAIL PROTECTED]> wrote:
> I'm curious about the speed trade off between a full table scan and just a
>  flat file search... Say I have a database with 2 records in it. If I do
>  a query like:
>
>  SELECT foo FROM table WHERE bar LIKE '%glaven%';
>
>  That will be a full text scan across the table. Would that be any faster
>  than just a regexp against a flat text file? Obviously you get the
>  advantages of SQL were it in a DB, versus a flat file. What other trade
>  offs are there?
>
>  My experience the above, is that in SQLITE it's still incredibly fast.

Every now and then we get questions about "will  be
fast or  be faster." The only definitive way to find
out is to benchmark, and the poser of the question is in a much better
position to answer than anyone else.

20,000 records means nothing at all... is it 20,000 records aka rows
of what? How big is the value of bar? Of course, in SQLite there is no
column width concept, so one could stuff in a 10,000 words novel in a
column of a row and drastically change the result.

That said, my sense is that probably grep against a 20K word file
would be faster than SQLite, but again, I am pulling that sense out of
thin air. I am too lazy to find a 20K file, grep against it for a
pattern, then make a table out of it, and SQL search against it using
SQLite. The definitive answer is only to be found, however, by
benchmarking.


>
>
>  --
>  Scott Baker - Canby Telcom
>  RHCE - System Administrator - 503.266.8253
>  ___
>  sqlite-users mailing list
>  sqlite-users@sqlite.org
>  http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>


-- 
Puneet Kishor http://punkish.eidesis.org/
Nelson Institute for Environmental Studies http://www.nelson.wisc.edu/
Open Source Geospatial Foundation (OSGeo) http://www.osgeo.org/
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


[sqlite] SQLite full text speed

2008-04-29 Thread Scott Baker
I'm curious about the speed trade off between a full table scan and just a 
flat file search... Say I have a database with 2 records in it. If I do 
a query like:

SELECT foo FROM table WHERE bar LIKE '%glaven%';

That will be a full text scan across the table. Would that be any faster 
than just a regexp against a flat text file? Obviously you get the 
advantages of SQL were it in a DB, versus a flat file. What other trade 
offs are there?

My experience the above, is that in SQLITE it's still incredibly fast.

-- 
Scott Baker - Canby Telcom
RHCE - System Administrator - 503.266.8253
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users