Re: CPU Consuming query. Sequential scan despite indexing.

2020-10-21 Thread aditya desai
Hi David, Thanks for the suggestion. Let me try to implement this as well. WIll get back to you soon. Regards, Aditya. On Thu, Oct 22, 2020 at 11:03 AM David G. Johnston < david.g.johns...@gmail.com> wrote: > On Wed, Oct 21, 2020 at 10:22 PM aditya desai wrote: > >> As per application team, it

Re: CPU Consuming query. Sequential scan despite indexing.

2020-10-21 Thread David G. Johnston
On Wed, Oct 21, 2020 at 10:22 PM aditya desai wrote: > As per application team, it is business requirement to show last 60 days >> worth data. >> > I didn't look deeply but it sounds like you are looking backwards into 60 days worth of detail every single time you perform the query and computing

Re: CPU Consuming query. Sequential scan despite indexing.

2020-10-21 Thread aditya desai
Hi, Kindly requesting for help on this. Thanks. -Aditya. On Tue, Oct 20, 2020 at 6:00 PM aditya desai wrote: > Hi Laurenz, > I created > > On Fri, Oct 16, 2020 at 2:06 PM Laurenz Albe > wrote: > >> On Thu, 2020-10-15 at 20:34 +0530, aditya desai wrote: >> > Below query always shows up on top

Re: CPU Consuming query. Sequential scan despite indexing.

2020-10-21 Thread aditya desai
Hi, Kindly requesting an update on this. Thanks. -Aditya. On Tue, Oct 20, 2020 at 6:26 PM aditya desai wrote: > > > On Mon, Oct 19, 2020 at 9:50 PM Michael Lewis wrote: > >> Reply to the group, not just me please. Btw, when you do reply to the >> group, it is best practice on these lists to re

Re: CPU Consuming query. Sequential scan despite indexing.

2020-10-20 Thread aditya desai
On Mon, Oct 19, 2020 at 9:50 PM Michael Lewis wrote: > Reply to the group, not just me please. Btw, when you do reply to the > group, it is best practice on these lists to reply in-line and not just > reply on top with all prior messages quoted. > Hi Michael, Please see below inline response. I

Re: CPU Consuming query. Sequential scan despite indexing.

2020-10-20 Thread aditya desai
Hi Laurenz, I created On Fri, Oct 16, 2020 at 2:06 PM Laurenz Albe wrote: > On Thu, 2020-10-15 at 20:34 +0530, aditya desai wrote: > > Below query always shows up on top in the CPU matrix. Also despite > having indexes it does sequential scans > > (probably because WHERE condition satisfies almo

Re: CPU Consuming query. Sequential scan despite indexing.

2020-10-20 Thread aditya desai
Hi Michael, Will follow standard practice going forward. We are in the process of rebuilding the PST environment equivalent to Prod where these Load tests were done. I will implement all these suggestions on that environment and reply back. Sincere apologies for the delay. Regards, Aditya. On Mon

Re: CPU Consuming query. Sequential scan despite indexing.

2020-10-19 Thread Michael Lewis
Reply to the group, not just me please. Btw, when you do reply to the group, it is best practice on these lists to reply in-line and not just reply on top with all prior messages quoted. On Sun, Oct 18, 2020 at 3:23 AM aditya desai wrote: > I tried vacuum full and execution time came down to hal

Re: CPU Consuming query. Sequential scan despite indexing.

2020-10-16 Thread Laurenz Albe
On Thu, 2020-10-15 at 20:34 +0530, aditya desai wrote: > Below query always shows up on top in the CPU matrix. Also despite having > indexes it does sequential scans > (probably because WHERE condition satisfies almost all of the data from > table). This query > runs on the default landing page i

Re: CPU Consuming query. Sequential scan despite indexing.

2020-10-15 Thread Michael Lewis
What version by the way? Do you get a faster execution if you disable sequential scan? Or set parallel workers per gather to 0? Your estimates look decent as do cache hits, so other than caching data or upgrading hardware, not sure what else there is to be done. Although... you are hitting 70k blo

CPU Consuming query. Sequential scan despite indexing.

2020-10-15 Thread aditya desai
Hi, Below query always shows up on top in the CPU matrix. Also despite having indexes it does sequential scans(probably because WHERE condition satisfies almost all of the data from table). This query runs on the default landing page in application and needs to fetch records in less that 100 ms wit