Re: Optimizing select count query which often takes over 10 seconds

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Alexander Farber <alexander(dot)farber(at)gmail(dot)com>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Optimizing select count query which often takes over 10 seconds
Date: 2013-01-27 19:41:30
Message-ID: CAMkU=1zy05dR7agh+orN9BqL6Otj+iziD4L0AvNruWSEN9PsJg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sun, Jan 27, 2013 at 9:25 AM, Alexander Farber
<alexander(dot)farber(at)gmail(dot)com> wrote:
> Hello -
>
> On Fri, Jan 25, 2013 at 7:42 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Jan Strube 2013-01-28 07:47:53 Re: Prevent out of memory errors by reducing work_mem?
Previous Message Jeff Janes 2013-01-27 18:41:40 Re: Finding common hstore key=>value pairs with hstore