I did some research on windowing functions since your post. They tend to be
slower since they ignore optimizations. For example, when using count(*),
indexes are used whenever possible to avoid hitting the table data and outer
joins are ignored altogether. And limited searches quit as soon as t
On Saturday, November 24, 2012 8:03:06 AM UTC+1, Peter of the Norse wrote:
> On Nov 21, 2012, at 3:53 AM, ?manu* wrote:
>
> > Suppose I have a queryset qs. For paginating purposes I need to do
> something like:
> >
> > count = qs.count()
> > qs = qs[0:100]
> >
> > Unfortunately this execute
On Nov 21, 2012, at 3:53 AM, ?manu* wrote:
> Suppose I have a queryset qs. For paginating purposes I need to do something
> like:
>
> count = qs.count()
> qs = qs[0:100]
>
> Unfortunately this executes the query twice, which I don't want.
Are you sure? This is such a common pattern that I sus
On Wed, Nov 21, 2012 at 5:53 AM, ?manu* wrote:
> count = qs.count()
> qs = qs[0:100]
>
> Unfortunately this executes the query twice, which I don't want.
while clearly non-optimal, i would guess that Postgresql's caches
should be able to skip most of the processing. Have you measured the
time im
Suppose I have a queryset qs. For paginating purposes I need to do
something like:
count = qs.count()
qs = qs[0:100]
Unfortunately this executes the query twice, which I don't want.
I can use postgresql windowing function like that:
qs = q.extra(select = {'count': 'COUNT(*) OVER()'})
to get
5 matches
Mail list logo