| From: | Andreas Joseph Krogh <andreas(at)visena(dot)com> |
|---|---|
| To: | Semen Yefimenko <semen(dot)yefimenko(at)gmail(dot)com> |
| Cc: | 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:26:07 |
| Message-ID: | VisenaEmail.2.8fd1850819f96dd.1794322fd82@tc7-visena |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
På torsdag 06. mai 2021 kl. 20:59:34, skrev Semen Yefimenko <
semen(dot)yefimenko(at)gmail(dot)com <mailto: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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Vijaykumar Jain | 2021-05-06 19:48:27 | Re: Very slow Query compared to Oracle / SQL - Server |
| Previous Message | Semen Yefimenko | 2021-05-06 18:59:34 | Re: Very slow Query compared to Oracle / SQL - Server |