Open
Bug 466246
Opened 16 years ago
Updated 2 years ago
Gloda could be better about reindexing as a result of flag changes
Categories
(MailNews Core :: Database, enhancement)
MailNews Core
Database
Tracking
(Not tracked)
NEW
People
(Reporter: davida, Unassigned)
References
Details
(Keywords: perf)
Right now gloda gets notifications of flag changes, including things like unread->read transitions. It then reindexes the message "normally", which doesn't mean redoing the full-text indexing, but everyhing else is as if it was a new message (or so I understand).
The optimization here is to do specific changes to the gloda indices when we know the precise nature of the changes, e.g. a message being read.
Reporter | ||
Comment 2•15 years ago
|
||
don't you love it when i file dupes of my own bugs?
Indexing isn't _that_ fast on slow machines, and if we get things like "show in conversation" in the message header, then messages-that-aren't-indexed might be more problematic than today.
But I'm confused: "I'm somewhat reluctant to pursue this since it seems likely to shoot reasonable extensions in the foot." -- which kind of extension would be broken?
Comment 3•15 years ago
|
||
(In reply to comment #2)
> Indexing isn't _that_ fast on slow machines, and if we get things like "show in
> conversation" in the message header, then messages-that-aren't-indexed might be
> more problematic than today.
From out-of-band discussion, glodaquilla is not going to actually show immediately when the message gets indexed. We only set the headers once we perform a SQLite commit, which tends to prefer to wait for idle or at least a number of seconds. Additionally, you need to move the mouse to cause a repaint of the tree-view.
The larger problem is that event-driven indexing does not interrupt long-running batch indexing. That definitely should be dealt with.
> But I'm confused: "I'm somewhat reluctant to pursue this since it seems likely
> to shoot reasonable extensions in the foot." -- which kind of extension would
> be broken?
Anything that depended on the state of the changed flags. For example, something that added a new attribute because you replied to a message. Perhaps it uses the fact that you replied to run a computationally expensive topic analysis on the text of the message. Or because you starred a message, etc. Since we only let you mutate the gloda message representation during indexing, it is important that we actually index it.
Updated•15 years ago
|
Severity: normal → enhancement
Summary: Gloda should be smarter about reindexing as a result of flag changes → Gloda could be smarter about reindexing as a result of flag changes
Target Milestone: Thunderbird 3.0b2 → ---
Updated•15 years ago
|
Keywords: perf
Summary: Gloda could be smarter about reindexing as a result of flag changes → Gloda could be better about reindexing as a result of flag changes
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•