Hi and thank you for your notes! > You really ought to include the output of EXPLAIN ANALYZE in cases such as > these (if it doesn't already point you to the culprit).
I'll do so, it takes quite long... > Most likely you'll find that the last condition added a sequential scan to > the query plan, Exactly! EXPLAIN says so. > which can have several causes/reasons. Are the estimated #rows close to the > actual #rows? Yes, this is the problem. I read that in such cases indexes are not read. However if the previous conditions are executed first, the result is zero or just a few rows and there is no need seq scan the whole values column. > Is b.value indexed? No, because it contains too long values for indexing. > How selective is the value you're matching it against (is it uncommon or > quite common)? Etc, etc. Zero to a few. > Meanwhile, it looks like most of your AND's are involved in joining tables a > and b. Perhaps it helps to use an explicit join instead of an implicit one? I am not quite sure what this means, but will read about it. There were 2 more suggestions, I'll try now everything and write back. Thank you very much for your help! T. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
