Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?

Поиск
Список
Период
Сортировка
So as the op, back to the original posting....

In the real world, what should I do?  Does it make sense to pull the "AND articles.indexed" clause into an outer query?  Will that query simply perform poorly on other arbitrary combinations of words?


I'm happy to test any given query against the same set of servers. If it involves a persistent change
it has to run on a test server).  For example, the Robert Haas method:
# ...
Total runtime: 254207.857 ms

# ALTER TABLE article_words ALTER COLUMN word_key SET STATISTICS 1000;
# ANALYZE VERBOSE article_words
INFO:  analyzing "public.article_words"
INFO:  "article_words": scanned 300000 of 1342374 pages, containing 64534899 live rows and 3264839 dead rows; 300000 rows in sample, 288766568 estimated total rows
ANALYZE
# ...
Total runtime: 200591.751 ms

# ALTER TABLE article_words ALTER COLUMN word_key SET STATISTICS 50;
# ANALYZE VERBOSE article_words
# ...
Total runtime: 201204.972 ms


Sadly, it made essentially zero difference.  Attached.


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

Предыдущее
От: Bryce Nesbitt
Дата:
Сообщение: Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
Следующее
От: Bryce Nesbitt
Дата:
Сообщение: Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?