Re: Optimizing select count query which often takes over 10 seconds - Mailing list pgsql-general

From Jeff Janes
Subject Re: Optimizing select count query which often takes over 10 seconds
Date
Msg-id CAMkU=1zy05dR7agh+orN9BqL6Otj+iziD4L0AvNruWSEN9PsJg@mail.gmail.com
Whole thread Raw
In response to Re: Optimizing select count query which often takes over 10 seconds  (Alexander Farber <alexander.farber@gmail.com>)
Responses Re: Optimizing select count query which often takes over 10 seconds  (Alexander Farber <alexander.farber@gmail.com>)
List pgsql-general
On Sun, Jan 27, 2013 at 9:25 AM, Alexander Farber
<alexander.farber@gmail.com> wrote:
> Hello -
>
> On Fri, Jan 25, 2013 at 7:42 PM, Jeff Janes <jeff.janes@gmail.com> wrote:

>> This sounds like a good idea.  But if the tournament is weekly why
>> would the job have to be hourly?  Why do the results of a weekly
>> tournament need to be 'live'?
>
> because for the current week
> the medals are displayed too.
>
> And when a player enters a top
> then he should get +1 medals and
> the one he pushed from the top -1 medals
>
> So even hourly isn't really good enough for me...
> It should be "live" stats.

Once the week is over, materialize the medals for that week.  Then the
live part of the query only needs to specify the currently live week,
not the entire history.  And in that case, the query should be quite
efficient if you have in index on both week and money.

Cheers,

Jeff


pgsql-general by date:

Previous
From: Jeff Janes
Date:
Subject: Re: Finding common hstore key=>value pairs with hstore
Next
From: Jan Strube
Date:
Subject: Re: Prevent out of memory errors by reducing work_mem?