Jose A Ortega Ruiz <j...@gnu.org> writes: > On Sun, Sep 18 2022, David Bremner wrote: > >> Jose A Ortega Ruiz <m...@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. _______________________________________________ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org