| From: | Vitaliy Garnashevich <vgarnashevich(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Postgres General <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Tricking the optimizer |
| Date: | 2018-04-18 21:06:17 |
| Message-ID: | 18bb3d30-a96c-f91b-3e42-45bb3527dd64@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
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:
-> Seq Scan on public.sys_user sys_user_1 (cost=0.00..27140.46
rows=1790 width=16) (actual time=0.136..28.413 rows=3289 loops=1)
Filter: COALESCE((((SubPlan 7) = 0) AND ((SubPlan 8) = 0) AND
((SubPlan 9) = 0)))
The estimate got closer to the actual number of rows.
Regards,
Vitaliy
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Adrian Klaver | 2018-04-18 22:03:01 | New website |
| Previous Message | greigwise | 2018-04-18 16:16:30 | postgres on physical replica crashes |