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