Re: R: [GENERAL] Postgres 9.6.1 big slowdown by upgrading 8.4.22

On 01/08/2017 07:30 AM, Job wrote: > Hi, here it is, excuse me for the delay: > > select * from webrecord > left join grucategorie on grucategorie.codcategoria=webrecord.categoria and > grucategorie.codgruppo='f50132' > left join grulist on grulist.nome=webrecord.dominio and >

Re: R: [GENERAL] Postgres 9.6.1 big slowdown by upgrading 8.4.22

Job writes: > Hi, here it is, excuse me for the delay: > ... > Execution time: 0.510 ms You're still not showing us the actual problem query (the one with EXISTS in it). Nor have you yet shown us any table schemas. *Please* go read the Slow_Query_Questions wiki

R: [GENERAL] Postgres 9.6.1 big slowdown by upgrading 8.4.22

Hi, here it is, excuse me for the delay: select * from webrecord left join grucategorie on grucategorie.codcategoria=webrecord.categoria and grucategorie.codgruppo='f50132' left join grulist on grulist.nome=webrecord.dominio and grulist.codgruppo='f50132' and grulist.stato in (1,2) left join

Re: [GENERAL] Postgres 9.6.1 big slowdown by upgrading 8.4.22

I would also like to add this: The explain analyze show that the index on that numeric field *is not* being used. I also try to set the seqscan off but that index continues not to be used. Maybe the problem is this? Thank you again! /F Hi, maybe I missed something, but it appears to me you

R: [GENERAL] Postgres 9.6.1 big slowdown by upgrading 8.4.22

I would also like to add this: The explain analyze show that the index on that numeric field *is not* being used. I also try to set the seqscan off but that index continues not to be used. Maybe the problem is this? Thank you again! /F -- Sent via pgsql-general mailing list

Re: [GENERAL] Catalog table which stores database level information

On 8 January 2017 at 05:18, Adrian Klaver wrote: > > On 01/07/2017 08:12 PM, Shrikant Bhende wrote: >> >> which are applicable to the respective >> database only, where can I get the info about the values of all >> parameters specified at database level. > > > Maybe

R: [GENERAL] Postgres 9.6.1 big slowdown by upgrading 8.4.22

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

Re: [GENERAL] R: Postgres 9.6.1 big slowdown by upgrading 8.4.22

FWIW you still haven't explained how the upgrade was performed. That might be a very important piece of information, because the 9.4 cluster might have hint bits set and/or the data may be mostly frozen, but the 9.6 cluster may not have that yet, resulting in higher CPU usage. We upgraded the

R: [GENERAL] Postgres 9.6.1 big slowdown by upgrading 8.4.22

Hi guys, >>FWIW you still haven't explained how the upgrade was performed. That might be >>a very important piece of information, because the 9.4 cluster might have >>hint bits set and/or the data may be mostly frozen, but the >>9.6 cluster may not have that yet, resulting in higher CPU usage.