From: David Bremner <david@tethera.net>
To: Jose A Ortega Ruiz <jao@gnu.org>, notmuch@notmuchmail.org
Subject: Re: Notmuch emacs client is slow when opening inbox.
Date: Mon, 19 Sep 2022 06:46:58 -0300 [thread overview]
Message-ID: <87wn9z7l2l.fsf@tethera.net> (raw)
In-Reply-To: <87r108p0xm.fsf@mail.jao.io>
Jose A Ortega Ruiz <jao@gnu.org> writes:
> On Sun, Sep 18 2022, David Bremner wrote:
>
>> Jose A Ortega Ruiz <mail@jao.io> writes:
>>>
>>> interesting! if we were to have this, i think i'd prefer pagination
>>> rather than increasing the limit and keeping the old ones, and make it
>>> work for tree searches too. and perhaps the limit (page size) could be
>>> a query parameter, so that one could have different page sizes for
>>> different queries. if that makes sense (and i'm not missing a better
>>> way already in place), i might try to implement it when i have a bit of
>>> time.
>>
>> Before going to far with pagination, maybe get Jani to recap the
>> difficulties he saw at the time that led him to propose the simpler
>> approach.
>>
>> I can think of a few issues, but I don't really know if they are
>> blockers.
>> - the result set is going to vary dynamically as messages are added and
>> removed from the database
>>
>> - As far as I can tell, there isn't really an easy way to jump to page
>> n of the results.
>
> fwiw, my idea here was to always run the full, non-paginated query, and
> populate its result buffer just as now, but show, instead of that
> buffer, an indirect buffer pointing to it, narrowed to the page at hand.
[snip]
> not as efficient as a limit/offset query per page, but i think the
> bottleneck here is in displaying results rather than running the query
> in most cases, isn't it?
Ah, indeed that sounds like a different approach than was previously
mooted. I guess it might be a simple-ish way of making the display more
lazy, which I agree is most likely the bottleneck most people are seeing.
prev parent reply other threads:[~2022-09-19 9:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-17 10:19 Notmuch emacs client is slow when opening inbox sam.hedin
2022-09-17 10:45 ` Teemu Likonen
2022-09-17 19:08 ` Sam Hedin
2022-09-17 17:52 ` Jose A Ortega Ruiz
2022-09-19 1:25 ` David Bremner
2022-09-19 2:12 ` Jose A Ortega Ruiz
2022-09-19 9:46 ` David Bremner [this message]
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
List information: https://notmuchmail.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wn9z7l2l.fsf@tethera.net \
--to=david@tethera.net \
--cc=jao@gnu.org \
--cc=notmuch@notmuchmail.org \
/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.
Code repositories for project(s) associated with this public inbox
https://yhetil.org/notmuch.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).