Re: [PERFORM] Query planner chooses index scan backward instead of better index option

2016-11-17 Thread Seckin Pulatkan
After Jeff Janes' reply, I have tried a couple of limit values and found at the current state of data, 90 was a change on the query planner. explain (analyze, buffers) select booking0_.* from booking booking0_ where (booking0_.customer_id in (select customer1_.id from customer cust

Re: [PERFORM] Query planner chooses index scan backward instead of better index option

2016-11-15 Thread Seckin Pulatkan
Thank you, Jeff for your reply. Yes, we tested with CTE as well but we are using Hibernate to generate the query and there are some more conditions that can be added if certain parameters supplied. For my knowledge, Hibernate is still not supporting CTE structures yet. That's why I will keep this

Re: [PERFORM] Query planner chooses index scan backward instead of better index option

2016-11-14 Thread Jeff Janes
On Mon, Nov 14, 2016 at 4:01 AM, Seckin Pulatkan wrote: > Hi, > > On our production environment (PostgreSQL 9.4.5 on > x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat > 4.8.5-4), 64-bit), one of our queries runs very slow, about 5 minutes . We > noticed that it does not us