Re: reducing number of ANDs speeds up query

From: "T(dot) E(dot) Lawrence" <t(dot)e(dot)lawrence(at)icloud(dot)com>
To: Alban Hertroys <haramrae(at)gmail(dot)com>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: reducing number of ANDs speeds up query
Date: 2013-01-12 11:41:32
Message-ID: 7A72BFB6-C851-4B64-AAC6-44C5CB0D305D@icloud.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message T. E. Lawrence 2013-01-12 11:50:54 Re: reducing number of ANDs speeds up query
Previous Message T. E. Lawrence 2013-01-12 11:38:13 Re: reducing number of ANDs speeds up query