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

On 01/09/2017 01:33 AM, Job wrote: Hi guys, Really thank you. Thanks to your help i solved the problem. For the record which problem(s)?: 1) Your original function issue. 2) The stand alone query you showed later. 3) Both. As said by Adrian: Caveats, it is morning here and coffee is

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

Hi guys, Really thank you. Thanks to your help i solved the problem. As said by Adrian: >>Caveats, it is morning here and coffee is still brewing, but I am not >>following. The left join limits grulist.stato to NULL, 1, 2. Your first >>condition catches the 1 value. Should not the second

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

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

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

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.

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

On 01/07/2017 06:44 AM, Job wrote: Hi guys, First of all excuse me but i really do not explain the problem, sorry... Are you being serious? You're complaining about a "big slowdown" for a query that goes from 1.5ms to 4ms? What is the actual problem you're trying to solve? Because I don't

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

Hi guys, First of all excuse me but i really do not explain the problem, sorry... >>Are you being serious? You're complaining about a "big slowdown" for a query >>that goes from 1.5ms to 4ms? >>What is the actual problem you're trying to solve? Because I don't see one in >>the above. Single

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

Hi guys, really much appreciated your replies. >> You might want to include the query plans for each server W e use a function, the explain analyze is quite similar: POSTGRESQL 8.4.22: explain analyze select 'record.com' where 'record.com' like '%.%' and function_cloud_view_orari('53',