Re: Tricking the optimizer

2018-04-18 Thread Vitaliy Garnashevich
We've tried to use "... WHERE coalesce(...)::bool;" on a test query: Before: ->  Seq Scan on public.sys_user sys_user_1  (cost=0.00..27140.46 rows=1 width=16) (actual time=0.105..38.627 rows=3289 loops=1)       Filter: (((SubPlan 7) = 0) AND ((SubPlan 8) = 0) AND ((SubPlan 9) = 0)) After: -> 

Re: Tricking the optimizer

2018-04-18 Thread Vitaliy Garnashevich
We'd rather avoid writing C code. We're trying to stick with the DB functionality provided by default. Could something like the following, in theory, make things at least somewhat better in our case (without using the selectivity override)? ... WHERE coalesce(securityFilter1 AND securityFilte

Re: Tricking the optimizer

2018-04-18 Thread Tom Lane
Vitaliy Garnashevich writes: > 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? If you don't mind writing some C code, you could create a dummy operator t