R: [GENERAL] Postgres 9.6.1 big slowdown by upgrading 8.4.22 - Mailing list pgsql-general

From Job
Subject R: [GENERAL] Postgres 9.6.1 big slowdown by upgrading 8.4.22
Date
Msg-id 88EF58F000EC4B4684700C2AA3A73D7A08054EACC251@W2008DC01.ColliniConsulting.lan
Whole thread Raw
In response to R: [GENERAL] Postgres 9.6.1 big slowdown by upgrading 8.4.22  (Job <Job@colliniconsulting.it>)
Responses R: [GENERAL] Postgres 9.6.1 big slowdown by upgrading 8.4.22  (Job <Job@colliniconsulting.it>)
List 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
twoconditions 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.1that takes CPU resources. 

The btree index is right for this (numeric) two conditions?

Thank you again!
/F

pgsql-general by date:

Previous
From: Thomas Kellerer
Date:
Subject: Re: [GENERAL] R: Postgres 9.6.1 big slowdown by upgrading 8.4.22
Next
From: Feike Steenbergen
Date:
Subject: Re: [GENERAL] Catalog table which stores database level information