To be honest, I just entered it as a word, and the client made it a URL
because it ends with a top-level domain, and looks like a domain name.
On Sun, Dec 23, 2018 at 7:15 PM Dan Davis wrote:
> Yes, https://datatables.net/, often miscalled jquery datatables, it is
> more like php datatables in
Yes, https://datatables.net/, often miscalled jquery datatables, it is more
like php datatables in its CGI parameters ;)
On Sun, Dec 23, 2018 at 2:51 PM Adam Johnson wrote:
> (I think you meant https://datatables.net/ ? ) :)
>
> On Sun, 23 Dec 2018 at 19:25, Dan Davis wrote:
>
>> Also, it can
(I think you meant https://datatables.net/ ? ) :)
On Sun, 23 Dec 2018 at 19:25, Dan Davis wrote:
> Also, it can be worse than one count query. When interacting with
> datables.net serverSide, you will need multiple count queries.
>
> On Sat, Dec 15, 2018, 10:32 AM Kye Russell
>> It might also
I would be strongly against misusing EXPLAIN like that inside Django, and I
feel keyset/cursor pagination is best if your going down this road.
I've got no concrete evidence for this opinion, but I feel like navigating
to an exact page is very rarely used and only then as a proxy for range
Also, it can be worse than one count query. When interacting with
datables.net serverSide, you will need multiple count queries.
On Sat, Dec 15, 2018, 10:32 AM Kye Russell It might also be worth looking at the alternative pagination methods
> offered by Django REST Framework as a source of
On Friday, December 21, 2018 at 10:18:04 AM UTC-5, Cristiano Coelho wrote:
>
> Let's not forget how the various *count *calls starts to kill your
> database when you get over 1 million rows (postgres at least).
>
> So far the only options I have found with postgres are:
> - Estimate count for non
Let's not forget how the various *count *calls starts to kill your database
when you get over 1 million rows (postgres at least).
So far the only options I have found with postgres are:
- Estimate count for non filtered queries: SELECT reltuples::BIGINT FROM
pg_class WHERE relname = '%s';
- If
Note: I'm only covering postgres here but the idea is pretty universal.
Good pagination starts with good sorting, so I'd suggest starting with
having a good primary key. Integer PK could be enough, could be not quite
(custom generator + postgres uuid field would be the next logical choice
for me,
It might also be worth looking at the alternative pagination methods
offered by Django REST Framework as a source of inspiration.
On Wednesday, December 5, 2018 at 8:15:22 PM UTC+8, Saleem Jaffer wrote:
>
> Hi all,
>
> The default paginator that comes with Django is inefficient when dealing
>
I think most people would typically sort/paginate on the primary key field,
which still exhibits a linear scan, where
the first few pages are fast and the last few pages take significantly
longer. Just wanted to call that out in case there
were listeners thinking an index solves the problem.
On 12/5/18 8:30 PM, Saleem Jaffer wrote:
Hi all,
The default paginator that comes with Django is inefficient when dealing
with large tables. This is because the final query for fetching pages
uses "OFFSET" which is basically a linear scan till the last index of
the current page. Does it make
There are already some packages on listed on djangopackages that claim to
implement different pagination strategies:
https://djangopackages.org/grids/g/pagination/
On Wed, 5 Dec 2018 at 12:37, Jason Johns wrote:
> https://www.citusdata.com/blog/2016/03/30/five-ways-to-paginate/ has some
>
https://www.citusdata.com/blog/2016/03/30/five-ways-to-paginate/ has some
interesting alternatives. I believe Django uses the first one. But the
others have some tradeoffs that might not apply to all the dbs that django
supports.
--
You received this message because you are subscribed to the
The preferred way for this kind of scenario is to make a third party
package. This let you release new version faster than the Django
development cycle and it's super easy to install thanks to tools like pip.
Once your solution is stable, if it's popular enough, it could be
incorporated into
Hi all,
The default paginator that comes with Django is inefficient when dealing
with large tables. This is because the final query for fetching pages uses
"OFFSET" which is basically a linear scan till the last index of the
current page. Does it make sense to have a better paginator which
15 matches
Mail list logo
