Tricking the optimizer - Mailing list pgsql-general

From Vitaliy Garnashevich
Subject Tricking the optimizer
Date
Msg-id 612dae0f-16b3-e5f8-7458-1ec38aea163c@gmail.com
Whole thread Raw
Responses Re: Tricking the optimizer  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Hi,

In order to implement some security features in our application, we 
sometimes append additional WHERE filters to our queries, so the filer 
in the end looks like:

SELECT ... FROM ... WHERE securityFilter1 AND securityFilter2 AND 
securityFilter3

In the EXPLAIN the filters look something like:

(((SubPlan 1) = 'foo') AND ((SubPlan 2) = 'bar') AND ((SubPlan 3) = 'baz'))

There are no applicable indexes and each filter clause looks opaque to 
the optimizer, so the optimizer is using some generic rules and assumes 
that each AND clause would reduce the total number of returned rows by 
some factor. The problem is that this is not usually the case, and 
usually the clauses would not filter out any rows at all. This leads to 
poor plans, when such query is a part of another bigger query.

Is there any trick to craft the query in such a way, so that to make the 
optimizer believe that the filters would not remove any rows, and all 
rows will likely be returned by the query?

Regards,
Vitaliy



pgsql-general by date:

Previous
From: Daniel Westermann
Date:
Subject: pg_locks.relation question
Next
From: Pavan Deolasee
Date:
Subject: Re: pg_locks.relation question