Jonatan Evald Buus writes:
> On 24 April 2014 23:25, Tom Lane wrote:
>> Jonatan Evald Buus writes:
>>> Why is "order2transaction_fk" being triggered twice? Is that because
>>> there're two affected rows?
>> No, I'd have expected a delete of multiple rows to show as calls=N,
>> not N separate en
Turns out yesterday we fixed a bug and introduced a new bug, which was
previously hidden by yet another bug which in turn we had fixed last
week... %)
In result last fix led to greatly increased number of requests to the
database.
But still, thanks for that, we found out about too frequent checkpo
Dmitry,
On Fri, Apr 25, 2014 at 11:31 AM, Дмитрий Шалашов wrote:
> Thanks, we'll try new autovacuum settings!
I think things with vacuum will be much better.
If not, try to find out if you have long running transaction (several
minutes or more) and try to avoid such them.
>
> First, I have to
On 25/04/14 09:47, Дмитрий Шалашов wrote:
> Half a day ago one of our production PG servers (arguably busiest one)
> become very slow; I went to investigate the issue and found that it runs
> simultaneously '(auto)VACUUM ANALYZE recommendations' - largest table on
> that server - and checkpoint, gi
> How is you filesystem under database exactly mount?
ext3 (rw)
Thanks, we'll try new autovacuum settings!
> That was happen after changing checkpoit_segments setting?
First, I have to say that load comes and go in waves - we don't yet
understood why.
All new waves have that behaviour - free dis
On Fri, Apr 25, 2014 at 10:29 AM, Дмитрий Шалашов wrote:
> Previously during load disk was 100% busy; now we have around 100 active
> state queries, 100% loaded proc, but disk is virtually idle...
That was happen after changing checkpoit_segments setting?
>
>
> Best regards,
> Dmitriy Shalashov
Dmitry,
How is you filesystem under database exactly mount? (mount -l) And
just in case, while increasing checkpoint_segments, better to increase
checkpoint_timeout, otherwise all checkpoints will be still frequent
because segment threshold will be never reached. You could monitor
your pg_stat_bgw
Hello
2014-04-25 10:48 GMT+02:00 Mehdi Ravanbakhsh :
> Hi All
>
> I have one big Pl/Pgsql function (about 1500 line code) , i can divided
> it to about 5 part and call each script from main script . In this case
> i need to know which way is faster .
>
> and some question about pgsql :
>
>
Hi All
I have one big Pl/Pgsql function (about 1500 line code) , i can divided it
to about 5 part and call each script from main script . In this case i
need to know which way is faster .
and some question about pgsql :
1- is pgsql engine open one process for each script ?
2- how i can chos
And right now we have a new kind of problem.
Previously during load disk was 100% busy; now we have around 100 active
state queries, 100% loaded proc, but disk is virtually idle... Normally we
have under 10 active queries.
Any hints on that?
Best regards,
Dmitriy Shalashov
2014-04-25 12:22 GMT+
Hi Ilya!
> Actually, thise two things are tightly bound and there is no chance to avoid
vacuum, you can only postpone it, this kind of work eventually supposed to
be done.
I understand that autovacuum has to be done, but not right after previous
autovacuum? And then again and again.
And after can
Hi Dmitry,
On Fri, Apr 25, 2014 at 9:47 AM, Дмитрий Шалашов wrote:
> cancelled autovacuum and it seems to help.
> In the morning autovacuum was back. And then it finished and I gone to work.
Actually, thise two things are tightly bound and there is no chance to
avoid vacuum, you can only postpo
Hi!
Half a day ago one of our production PG servers (arguably busiest one)
become very slow; I went to investigate the issue and found that it runs
simultaneously '(auto)VACUUM ANALYZE recommendations' - largest table on
that server - and checkpoint, giving a 100% disk load, that resulted with
que
13 matches
Mail list logo
