Re: Help with tuning this query (with explain analyze finally)

Поиск
Список
Период
Сортировка
От Ken
Тема Re: Help with tuning this query (with explain analyze finally)
Дата
Msg-id 000e01c520d8$4f899a90$780ba8c0@javadude
обсуждение исходный текст
Ответ на Help with tuning this query  ("Ken Egervari" <ken@upfactor.com>)
Ответы Re: Help with tuning this query (with explain analyze finally)  (John Arbash Meinel <john@arbash-meinel.com>)
Список pgsql-performance
Richard,

What do you mean by summary table?  Basically a cache of the query into a
table with replicated column names of all the joins?  I'd probably have to
whipe out the table every minute and re-insert the data for each carrier in
the system.  I'm not sure how expensive this operation would be, but I'm
guessing it would be fairly heavy-weight.  And maintaince would be a lot
harder because of the duplicated columns, making refactorings on the
database more error-prone.  Am I understanding your suggestion correctly?
Please correct me if I am.

> Can you turn the problem around? Calculate what you want for all users
> (once every 60 seconds) and stuff those results into a summary table. Then
> let the users query the summary table as often as they like (with the
> understanding that the figures aren't going to update any faster than once
> a minute)


В списке pgsql-performance по дате отправления:

Предыдущее
От: Richard Huxton
Дата:
Сообщение: Re: Help with tuning this query (with explain analyze finally)
Следующее
От: John Arbash Meinel
Дата:
Сообщение: Re: Help with tuning this query (with explain analyze finally)