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)
|
Список | 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 по дате отправления: