From: | Vijaykumar Jain <vijaykumarjain(dot)github(at)gmail(dot)com> |
---|---|
To: | Andreas Joseph Krogh <andreas(at)visena(dot)com> |
Cc: | Semen Yefimenko <semen(dot)yefimenko(at)gmail(dot)com>, Alexey M Boltenkov <padrebolt(at)yandex(dot)ru>, luis(dot)roberto(at)siscobra(dot)com(dot)br, pgsql-performance <pgsql-performance(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Very slow Query compared to Oracle / SQL - Server |
Date: | 2021-05-06 19:48:27 |
Message-ID: | CAM+6J95d0hbx8f0-QcAUf5QffKs8m_xV4TnD5Wa+==YZ+io=PQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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(at)visena(dot)com>
wrote:
> På torsdag 06. mai 2021 kl. 20:59:34, skrev Semen Yefimenko <
> semen(dot)yefimenko(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alexey M Boltenkov | 2021-05-06 19:58:30 | Re: Very slow Query compared to Oracle / SQL - Server |
Previous Message | Andreas Joseph Krogh | 2021-05-06 19:26:07 | Re: Very slow Query compared to Oracle / SQL - Server |