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.
_______________________________________________
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org