jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ard Schrijvers" <a.schrijv...@hippo.nl>
Subject RE: Inefficient/useless UUIDDocId cache ( was : Search performance : MultiIndex)
Date Tue, 13 Nov 2007 09:46:02 GMT
sry for not indenting, i am using a webclient: 
 
Ard Schrijvers wrote:
> It boils down IIUC, that only
> the readers that where involved during a commit would have to be
> re-calculated if getDocumentNumber is called, right?

----------------------------------------------------------------------------------
to be precise the UUIDDocIds that refer to readers that were involved in a 
commit need to be re-calculated. There are two occasions where the document 
number needs to be recalculated:

- the parent node is modified, which means it re-indexed and effectively is 
deleted from the index and added again. modifying a node always means that it 
'travels' from an old index segment to a younger one. this might actually give 
use some optimization potential when we need to get a document number again in a 
UUIDDocId.

- index segments are merged. again nodes travel from older indexes to a younger one.

----------------------------------------------------------------------------------

And perhaps, all docNumbers change when index segments have changed/merged and a new MultiIndexReader
is created with different offset's. 

It is what I just described in https://issues.apache.org/jira/browse/JCR-1214. Anyway, think
during implementing I'll probably will find the problems anyway, so if we miss a thing now,
I'll probably run into it during tests.

I'll try to get back on it later this week (am out of the office now), so can't work on it)

Regards Ard


"hmm, did I miss anything?

regards
  marcel"


Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message