Re: performace review

Поиск
Список
Период
Сортировка
От Jonathan Vanasco
Тема Re: performace review
Дата
Msg-id BB4C0D53-147B-480A-A175-0DB5848C138E@2xlp.com
обсуждение исходный текст
Ответ на Re: performace review  (Chris Browne <cbbrowne@acm.org>)
Список pgsql-general
On Oct 7, 2006, at 6:41 PM, Chris Browne wrote:
> This could also be a situation where adding a few useful indexes might
> fix a lot of ills.  Better to try to help fix the problems so as to
> help show that the comparisons are way off base rather than to simply
> cast stones...

i'm too tight for cash to afford being wrong right now...

but I'd otherwise bet that the issue was from not vacuum analyzing

i've routinely had 3,9,12, i think even a 14 table join that would
take forever to run...

until i realized that i added/dropped an index and forgot to run
analyze.  then they all work within a matter of split seconds. all of
them.

i've seen not just dramatic, but drastic , changes in performance and
the planner's output before and after a vacuum analyze of the db.

i'm really confident thats the problem.  unfortunately, they have a
max_db contact email, and not a postgres.  so i don't know who to
check with to see if they ran it or not.

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

Предыдущее
От: Ron Johnson
Дата:
Сообщение: Re: increment row number function question
Следующее
От: "Jaime Casanova"
Дата:
Сообщение: Re: How to force the parser to use index scan instead of sequential scan