| From: | Job <Job(at)colliniconsulting(dot)it> |
|---|---|
| To: | Job <Job(at)colliniconsulting(dot)it>, 'Tomas Vondra' <tomas(dot)vondra(at)2ndquadrant(dot)com>, Alban Hertroys <haramrae(at)gmail(dot)com> |
| Cc: | Rob Sargent <robjsargent(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
| Subject: | R: Postgres 9.6.1 big slowdown by upgrading 8.4.22 |
| Date: | 2017-01-08 11:24:44 |
| Message-ID: | 88EF58F000EC4B4684700C2AA3A73D7A08054EACC251@W2008DC01.ColliniConsulting.lan |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Hi guys,
Here is an update, i think i have found the right statement that bring Postgresql 9.6.1 under heavy-use of resources (CPU) in a massive benchmark.
I only try to remove one simple, but very simple, condition:
and (grulist.stato is null or grulist.stato!=2)
Grulist.stato field is numeric and has a btree index on it.
Very strange: if i leave only one condition (example: grulist.stato is null) no heavy-cpu use occurred (but i need the two conditions with the OR).
But when combyning the two conditions (grulist.stato is null OR grulist.stato != 2) something happens...
The single explain analyze is very fast and maybe there is something that create a strange condition for postgresql 9.6.1 that takes CPU resources.
The btree index is right for this (numeric) two conditions?
Thank you again!
/F
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Feike Steenbergen | 2017-01-08 11:46:48 | Re: Catalog table which stores database level information |
| Previous Message | Thomas Kellerer | 2017-01-08 11:21:08 | Re: R: Postgres 9.6.1 big slowdown by upgrading 8.4.22 |