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:
->
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
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
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
