On 2022-03-17 3:41 PM, Dave wrote:
I’m a big believer in the right tool for the job. Like what said before if
you’re doing just a field:value query or four and no complications, sure use a
standard rdbms. But if you inform the client that something like
Leaves And whitm* title^3 with bf:title^
I’m a big believer in the right tool for the job. Like what said before if
you’re doing just a field:value query or four and no complications, sure use a
standard rdbms. But if you inform the client that something like
Leaves And whitm* title^3 with bf:title^3 author ^2
Is possible, the conver
This is really a question of how big the haystack is and what sort of search
task users are trying to accomplish.
If there is no IDF (a mistake I did *not* make at https://www.indexengines.com/
despite using home-grown search BTW), then there is an assumption both on the
size of the documents b
Ok Charlie, Eric,
we are on the same page.
I agree it's definitely possible with some custom proxy work on both Quepid
and RRE, I meant it's not possible to directly point to the DB (for example
via JDBC).
Thanks!
Cheers
--
Alessandro Benedetti
Apache Lucene/Solr PMC member
You are, indeed :-).
What appears to be the problem - and I'm not sure yet, but it sure seems like a
good culprit - is that Postgres search, for reasons that mystify me, was
implemented with TF but no notion of IDF. There are various extensions that add
IDF-like properties to Postgres search.
Hi,
Sort of. You can make Quepid talk to other search engines with a 'shim'
layer to make the response look like a Solr or Elasticsearch response.
Quepid can send pretty much anything to a HTTP API as the query. There's
a project called iSpy that is a prototype for this but I think it's
curre
What I’ve done to compare other search engines with RRE and Quepid is to put a
proxy in the middle that converts your query into what looks like a Solr
request/response ;-). This works great for custom Search API’s, and I *guess*
you could do it with database backed search?
Now we are probably
This is an interesting question.
I second both comments so far (from Eric and David), but I am afraid at the
moment the open-source tools for search quality evaluation can't really
compare Postgres to Solr.
As far as I know, both Quepid(Eric correct me if I am wrong) and RRE(
https://github.com/Sea
I hate to spam this entire list.. I have tried every automated way I know
to get off this list. Can someone please unsubscribe me from the
us...@solr.apach.org email list.
Again, I am very sorry to disturb your Saturday (or Sunday) with this mass
email.
On Fri, Mar 4, 2022 at 8:33 AM Bayer, Sa
Hello Sam,
You are a familiar name from my MITRE days :-)
Check out Solr's feature list and see how it compares to that of Postgres.
If you are only doing the most basic default relevancy ranked top-N search
with default text analysis, then the tech/maintenance overhead might not be
worth it. I'
In general when evaluating a new option for my search engine, I like to take a
set of queries that represent my users, with some head, and some tail queries.
Rate the results that you are getting, to get a concrete numbers on the
quality of search. Then, take that rated “judgement set” and
11 matches
Mail list logo
