From: wmorgan-sup@masanjin.net (William Morgan)
Subject: [sup-talk] new in next: faster saving and bigger indexes
Date: Sun, 24 Feb 2008 09:15:32 -0800 [thread overview]
Message-ID: <1203871982-sup-7942@south> (raw)
I've just merged in a changeset that makes Sup store message body
content in the Ferret index. (They've always been indexed, but now
they're stored as well.) This means that changing the labels on a
message can be a copy operation of the previous Ferret document, rather
than requiring downloading and parsing the original message to create a
new Ferret document.
So, this should have two effects:
1. The Ferret index size will expand by about 50%. Sorry.
2. Tweaking message labels should be much, much faster, since the
message no longer has to be downloaded from the source in order to
change the labels. If you've ever tried to label a large IMAP thread,
you no longer have to wait 5 minutes just to save. :)
The index size increase is unfortunate, but it's something that has to
happen anyways if we want search-results-mode to have matching text in
the snippets, which is in the future TODO.
The change was made in such a way that it's incrementally applied
whenever a message is saved or changed in the Ferret index. So, if you
want the above behavior on all messages immediately, you must do
sup-sync --all on a source (which will require downloading each
message). Otherwise, you will get the slow behavior (message body needs
to be downloaded from the source) the first time you save a message
after merging this change, and the fast behavior (no downloading
required) on all subsequent times.
I'm planning on committing another change in the near future that will
also require a sup-sync --all, so you might want to hold out for that if
you have a lot of messages. (I'm planning to have message state be
duplicated outside the Ferret index, so that Ferret index corruption is
a nuisance rather than a nightmare.)
There's also a potential next step here where no interaction with
external sources is *ever* required except at poll time, which would
mean IMAP would become actually useable. (The other option being just
figure out why the Ruby IMAP library is so incredibly slow.)
--
William <wmorgan-sup at masanjin.net>
next reply other threads:[~2008-02-24 17:15 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-24 17:15 William Morgan [this message]
2008-02-27 15:19 ` Marcus Williams
2008-02-27 17:16 ` William Morgan
2008-02-28 18:25 ` William Morgan
2008-02-28 23:05 ` Marcus Williams
2008-02-29 0:28 ` William Morgan
2008-02-29 1:27 ` William Morgan
2008-02-27 18:55 ` Christopher Warrington
2008-02-28 17:23 ` William Morgan
2008-03-03 7:42 ` Christopher Warrington
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1203871982-sup-7942@south \
--to=wmorgan-sup@masanjin.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox