So how about the removal of the "AND" clause? On a test server, this
drops the query from 201204 to 438 ms.
Is this just random, or is it a real solution that might apply to any
arbitrary combination of words?
Attached are three test runs:
Total runtime: 201204.972 ms
Total runtime: 437.766 ms
Tot
Tom Lane wrote:
> Given that it estimated 1 row out of "words" (quite correctly) and 12264
> rows out of each scan on article_words, you'd think that the join size
> estimate would be 12264, which would be off by "only" a factor of 3 from
> the true result. Instead it's 23, off by a factor of 200
On Wed, Feb 10, 2010 at 8:52 PM, Bryce Nesbitt wrote:
> If you guys succeed in making this class of query perform, you'll have beat
> out the professional consulting firm we hired, which was all but useless!
> The query is usually slow, but particular combinations of words seem to make
> it obscen
Bryce Nesbitt writes:
> The query plans are now attached (sorry I did not start there: many
> lists reject attachments). Or you can click on "text" at the query
> planner analysis site http://explain.depesz.com/s/qYq
At least some of the problem is the terrible quality of the rowcount
estimates i
If you guys succeed in making this class of query perform, you'll have
beat out the professional consulting firm we hired, which was all but
useless! The query is usually slow, but particular combinations of
words seem to make it obscenely slow.
The query plans are now attached (sorry I did not s
That sure looks like the source of the problem to me too. I've seen similar
behavior in queries not very different from that. It's hard to guess what the
problem is exactly without having more knowledge of the data distribution in
article_words though.
Given the results of analyze, I'd try to
On Wed, Feb 10, 2010 at 3:29 AM, Bryce Nesbitt wrote:
> Or, if you want to actually read that query plan, try:
> http://explain.depesz.com/s/qYq
Much better, though I prefer a text attachment... anyhow, I think the
root of the problem may be that both of the subquery scans under the
append node
2010/2/10 Bryce Nesbitt :
> Or, if you want to actually read that query plan, try:
> http://explain.depesz.com/s/qYq
>
hello,
check your work_mem sesttings. Hash join is very slow in your case.
Pavel
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make c
Or, if you want to actually read that query plan, try:
http://explain.depesz.com/s/qYq
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
