Re: A very long running query....
От | Ioannis Anagnostopoulos |
---|---|
Тема | Re: A very long running query.... |
Дата | |
Msg-id | 500B01E8.1000405@anatec.com обсуждение исходный текст |
Ответ на | Re: A very long running query.... (Claudio Freire <klaussfreire@gmail.com>) |
Список | pgsql-performance |
On 21/07/2012 20:19, Claudio Freire wrote: > On Sat, Jul 21, 2012 at 4:16 PM, Ioannis Anagnostopoulos > <ioannis@anatec.com> wrote: >> I am not sure that I can see an improvement, at least on src_id that have >> lots of msg_id per day the query never returned even 5 hours later running >> "exaplain analyze". For smaller src_id >> (message wise) there might be some improvement or it was just the analyse >> that I run. As I said the stats goes quickly out of scope because of the big >> number of updates. So it looks like that >> it is not the "funny" "where" concatenation or some kind of index >> construction problem. Which brings us back to the issue of the >> "statistics_target" on per column. My problem is that given the >> query plan I provided you yesterday, I am not sure which columns >> statistics_target to touch and what short of number to introduce. Is there >> any rule of thumb? > What's the size of your index, tables, and such? > In GB I mean, not tuples. The message_copies_wk2 that I currently hit is 13GB and 11 the Indexes, the ship_a_pos_messages_wk2 is 17GB and 2.5MB the index and the ship_objects is 150MB table and index approx. Yiannis
В списке pgsql-performance по дате отправления: