Can anyone point me to an explanation/documentation about why a view index is enlarged considerably when the view includes documents that have readers fields. This is true regardless of the reader fields being used in any view column.
This is nowhere to be found in the documentation i read thusfar.
I have read a lot of documentation about performance, and i know that using reader fields slows down view perfomance, but the documentation only explained this in terms of the server having to search through the data in order to try to serve up enough documents.
Very interesting. I’ll have to test that the next time I do my performance testing (7.5?) At any rate, I’m not too surprised, as the view has to be aware of all readernames fields (as long as they’re also SUMMARY) in order to expedite its check of each user who opens the view.
But I hadn’t thought of seeing whether that information would be stored in the view index itself. Again, very interesting.
But in any case, you should typically avoid having your readernames fields be huge by using groups and roles. If you have hundreds or thousands of individual names, I would worry most about maintaining those names.
I hadn’t heard about this, but it’s not surprising. I’m sure what you’re seeing, must be a copy of the readers items being stored along with each view row. This will help performance because Notes can decide whether each row is visible to the current user, without opening each document and searching it for readers fields.
Well, i had not heard about it either, untill we ran into trouble in a project where the performance of an application dropped to unacceptably low levels.
The interesting thing is that for reader fields with just one or two values, the view index size is the same compared to documents that have only names fields or authors fields, but the more values the reader fields contain, the more the view index size is enlarged. The view index may contain repeated entries for each identified unique reader, who shares document read access with other readers, i imagine.
Well, it does not help performance, i can assure you.
It appears that the view index sizes can be reduced a factor 3 to 6 when removing the readers fields or setting the IsSummary flag to false. The database could be reduced from 6.4 gig to less than 1.5 gig, just by ‘stripping’ some reader fields that contained a set of user names (Lotus Workflow Application :=) ).