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

2017-01-09 Thread Adrian Klaver
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

2017-01-09 Thread Job
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

2017-01-08 Thread Adrian Klaver
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

2017-01-08 Thread Tom Lane
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

2017-01-08 Thread Job
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

2017-01-08 Thread Chris Mair
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

2017-01-08 Thread Job
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

2017-01-08 Thread Job
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

2017-01-08 Thread Job
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: [GENERAL] Postgres 9.6.1 big slowdown by upgrading 8.4.22

2017-01-07 Thread Tom Lane
Tomas Vondra writes: > No. now() calls GetCurrentTransactionStartTimestamp(), so it does not > call gettimeofday() and so the clock source overhead is pretty much > irrelevant. Moreover it's marked as 'stable' which makes repeated calls > unnecessary. Yeah. My

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

2017-01-07 Thread Tomas Vondra
On 01/08/2017 01:12 AM, Alban Hertroys wrote: On 7 Jan 2017, at 15:44, Job wrote: ... This is what it happens: Postgres 8.4.22 Medium average load 1.5/2.0 Further queries respond very quickly Postgres 9.6.1 Medium average load 18.0/20.0 !! Further queries are

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

2017-01-07 Thread Alban Hertroys
> On 7 Jan 2017, at 15:44, 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

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

2017-01-07 Thread Adrian Klaver
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

2017-01-07 Thread Job
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

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

2017-01-07 Thread Tomas Vondra
On 01/07/2017 04:43 AM, Venkata B Nagothi wrote: On Sat, Jan 7, 2017 at 2:56 AM, Job > wrote: __ Hi guys, really much appreciated your replies. >> You might want to include the query plans for each server W

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

2017-01-06 Thread Venkata B Nagothi
On Sat, Jan 7, 2017 at 2:56 AM, Job wrote: > 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

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

2017-01-06 Thread Melvin Davidson
On Fri, Jan 6, 2017 at 4:56 PM, Alban Hertroys wrote: > > > On 6 Jan 2017, at 16:56, Job wrote: > > > > W e use a function, the explain analyze is quite similar: > > POSTGRESQL 8.4.22: > > Total runtime: 1.531 ms > > > > POSTGRES 9.6.1: > >

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

2017-01-06 Thread Alban Hertroys
> On 6 Jan 2017, at 16:56, Job wrote: > > W e use a function, the explain analyze is quite similar: > POSTGRESQL 8.4.22: > Total runtime: 1.531 ms > > POSTGRES 9.6.1: > Execution time: 4.230 ms Are you being serious? You're complaining about a "big slowdown" for

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

2017-01-06 Thread Job
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',

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

2017-01-05 Thread Tom Lane
Job writes: > Could you please help me? There's advice here on how to ask this type of question with enough detail to get answers: https://wiki.postgresql.org/wiki/Slow_Query_Questions regards, tom lane -- Sent via pgsql-general mailing

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

2017-01-05 Thread Rob Sargent
On 01/05/2017 10:18 AM, Job wrote: Hello guys, a very strange thing: after upgrading from 8.4.22 to 9.6.1 i noticed, under heavy beanchmarks, a really slowdown of Postgresql 9.6.1, with the machine really "without breath". By replacing Postgresql 8.4.22 evberything returns working fine.

[GENERAL] Postgres 9.6.1 big slowdown by upgrading 8.4.22

2017-01-05 Thread Job
Hello guys, a very strange thing: after upgrading from 8.4.22 to 9.6.1 i noticed, under heavy beanchmarks, a really slowdown of Postgresql 9.6.1, with the machine really "without breath". By replacing Postgresql 8.4.22 evberything returns working fine. With three days of investigation, i come