On Monday 31 July 2006 14:07, Istvan Albert wrote:
> > I am expecting an answer like: "You are crazy: db native searches will
> > always be faster"
>
> You are crazy: swish-e searches will always be faster.
>
> Swish-e was created for indexing/searching documents. The only issue at
> hand is wheth
> I am expecting an answer like: "You are crazy: db native searches will always
> be faster"
You are crazy: swish-e searches will always be faster.
Swish-e was created for indexing/searching documents. The only issue at
hand is whether the speedup you get is worth the trouble of having to
integ
On Monday 31 July 2006 11:04, Kevin wrote:
> My use of swish-e is clearly different that yours. The indexer part of
> swish-e is run only periodically (say, nightly) with a `swish-e -S prog
> -i ./generate_index.py`
>
> this creates an index file that the SwishE python api queries
Hey Kevin,
My use of swish-e is clearly different that yours. The indexer part of
swish-e is run only periodically (say, nightly) with a `swish-e -S prog
-i ./generate_index.py`
this creates an index file that the SwishE python api queries
--~--~-~--~~~---~--~~
You rec
Hi all,
I saw the recent posts about Search Functionality and how some of you, Adrian
included, are using it for searching. I'd like your opinion on whether
Swish-e would make sense for searching/indexing 12 varchar(<=255) fields in a
large table (~10M records).
The search is currently takin
5 matches
Mail list logo
