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
theculprit).
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
executedfirst, 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
explicitjoin 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.
