diff options
author | Eric Wong <e@80x24.org> | 2020-12-05 11:10:45 +0000 |
---|---|---|
committer | Eric Wong <e@80x24.org> | 2020-12-05 21:41:52 +0000 |
commit | 4b551c884a648b45ec6b5465efd9fb67f85f0055 (patch) | |
tree | 922b3ba8a252589e6335703499c0dc640d3950f5 /lib/PublicInbox/OverIdx.pm | |
parent | 525555d14118f92f86be54c683f797089c52a78d (diff) | |
download | public-inbox-4b551c884a648b45ec6b5465efd9fb67f85f0055.tar.gz |
Since IMAP search (either with Isearch or traditional per-Inbox search) only returns UIDs, we can safely set the limit to the UID slice size(*). With isearch, we can also trust the Xapian result to fit any docid range we specify. Limiting Xapian results to 1000 was making ->ALL docid <=> per-Inbox UID impossible since results could overlap between ranges unpredictably. Finally, we can map the ->ALL docids into per-Inbox UIDs and show them to the client in the UID order of the Inbox, not the docid order of the ->ALL extindex. This also lets us get rid of the "uid:" query parser prefix and use the Xapian::Query API directly to reduce our search prefix footprint. For mbox.gz downloads in WWW, we'll also make a best effort to preserve the order from the Inbox, not the order of extindex; though it's possible large result sets can have non-overlapping windows. (*) by definition, UID slice size is a "safe" value which shouldn't OOM either the server or clients.
Diffstat (limited to 'lib/PublicInbox/OverIdx.pm')
0 files changed, 0 insertions, 0 deletions