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

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: Optimizing select count query which often takes over 10 seconds
Дата
Msg-id CAMkU=1zy05dR7agh+orN9BqL6Otj+iziD4L0AvNruWSEN9PsJg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Optimizing select count query which often takes over 10 seconds  (Alexander Farber <alexander.farber@gmail.com>)
Ответы Re: Optimizing select count query which often takes over 10 seconds  (Alexander Farber <alexander.farber@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: Finding common hstore key=>value pairs with hstore
Следующее
От: Jan Strube
Дата:
Сообщение: Re: Prevent out of memory errors by reducing work_mem?