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@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
