Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk? - Mailing list pgsql-performance

From Bryce Nesbitt
Subject Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
Date
Msg-id 4B765B94.4000602@obviously.com
Whole thread Raw
In response to Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?  (Pierre Frédéric Caillaud<lists@peufeu.com>)
Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-performance
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 by date:

Previous
From: Bryce Nesbitt
Date:
Subject: Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
Next
From: Bryce Nesbitt
Date:
Subject: Re: Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?