Re: Very slow Query compared to Oracle / SQL - Server
Vijaykumar Jain <vijaykumarjain.github@gmail.com>
From: Vijaykumar Jain <vijaykumarjain.github@gmail.com>
To: Andreas Joseph Krogh <andreas@visena.com>
Cc: Semen Yefimenko <semen.yefimenko@gmail.com>,
Alexey M Boltenkov <padrebolt@yandex.ru>, luis.roberto@siscobra.com.br, pgsql-performance <pgsql-performance@lists.postgresql.org>
Date: 2021-05-06T19:48:27Z
Lists: pgsql-performance
I am not sure, if the goal is just for the specific set of predicates or performance in general. Also from the explain plan, it seems there is still a significant amount of buffers read vs hit. That would constitute i/o and may add to slow result. What is the size of the table and the index ? Is it possible to increase shared buffers ? coz it seems, you would end up reading a ton of rows and columns which would benefit from having the pages in cache. although the cache needs to be warmed by a query or via external extension :) Can you try tuning by increasing the shared_buffers slowly in steps of 500MB, and running explain analyze against the query. If the Buffers read are reduced, i guess that would help speed up the query. FYI, increasing shared_buffers requires a server restart. As Always, Ignore if this does not work :) Thanks, Vijay On Fri, 7 May 2021 at 00:56, Andreas Joseph Krogh <andreas@visena.com> wrote: > På torsdag 06. mai 2021 kl. 20:59:34, skrev Semen Yefimenko < > semen.yefimenko@gmail.com>: > > Yes, rewriting the query with an IN clause was also my first approach, but > I didn't help much. > The Query plan did change a little bit but the performance was not > impacted. > > > CREATE INDEX idx_arcstatus_le1 ON schema.logtable ( archivestatus ) > where (archivestatus <= 1) > ANALYZE schema.logtable > > > This resulted in this query plan: > [...] > > > I assume (4000,4001,4002) are just example-values and that they might be > anything? Else you can just include them in your partial-index. > > -- > Andreas Joseph Krogh > -- Thanks, Vijay Mumbai, India