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@xxxxxxxxxx> wrote:
På torsdag 06. mai 2021 kl. 20:59:34, skrev Semen Yefimenko <semen.yefimenko@xxxxxxxxx>: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
