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
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
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
>
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
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
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
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
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
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.
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
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
> 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
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
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
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
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
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:
> >
> 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
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',
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
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.
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
22 matches
Mail list logo