mailinglists@net-virtual.com scribbled on 7/6/05 4:59 PM:

> .. Using this, Postgres will summarize the counts for all the levels
> above 4.  I hope this makes sense.  I tried just selecting the category
> from the data table and processing them in my script, but this was slower
> then letting Postgres do it.  This is the fundamental area where I need to
> get a performance boost.  Can Swish-E help me out here?
> 

seems like you would need to be clever in defining your XML and then playing 
with the metanames (maybe using attributes to define "subfields"?).




> How severe, if at all,
> would the performance be of searching 202 medium sized indexes and up to
> 202 very small indexes as opposed to one large index?

I sometimes get errors about too many open files. That may be platform or 
filesystem related, rather than strictly Swish-e related. I would expect 
searching a single index to be faster than many smaller indexes.


> 
> As a third matter, throughout the day records are deleted from the
> database.  I need these records to come out of the index ASAP.   I am okay
> in the user-interface just saying "This record no longer exists" until a
> full-index is built, but I'm wondering if there is some way to tell
> Swish-E to exclude certain records from the results it gives me?  Would it
> be as simple as maintaining a table of "deleted ids" and in adding
> something to the query string tell Swish-E to not include records which
> contain those IDs?

I have a special metaname defined for each record called '_status' which I can 
then search against:

  foo and _status=(not deleted)

In order to do that, I create an index for each record that gets modified, and 
search those mods plus the main index. It gets a little tricky checking for race 
conditions, so I'm oversimplifying it here in this description.

-- 
Peter Karman  .  http://peknet.com/  .  peter(at)not-real.peknet.com