From: | "Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
---|---|
To: | "Yan Chunlu *EXTERN*" <springrider(at)gmail(dot)com>, "Craig Ringer" <ringerc(at)ringerc(dot)id(dot)au> |
Cc: | <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: how could select id=xx so slow? |
Date: | 2012-07-11 08:23:07 |
Message-ID: | D960CB61B694CF459DCFB4B0128514C2082464D4@exadv11.host.magwien.gv.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Yan Chunlu wrote:
> I have logged one day data and found the checkpoint is rather
frequently(detail:
> https://gist.github.com/3088338) Not sure if it is normal, but the
average time of checkpoint is
> about 100sec~200sec, it seems related with my settings:
>
> 574 checkpoint_segments = 64
> 575 wal_keep_segments = 5000
>
> I set checkpoint_segments as a very large value which is because
otherwise the slave server always can
> not follow the master, should I lower that value?
You mean, you set wal_keep_segments high for the standby, right?
wal_keep_segments has no impact on checkpoint frequency and intensity.
You are right that your checkpoint frequency is high. What is your value
of checkpoint_timeout?
You can increase the value of checkpoint_segments to decrease the
checkpoint frequence, but recovery will take longer then.
> or the slow query is about something else? thanks!
I guess the question is how saturated the I/O system is during
checkpoints. But even if it is very busy, I find it hard to believe
that such a trivial statement can take extremely long.
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Yan Chunlu | 2012-07-11 11:40:35 | Re: how could select id=xx so slow? |
Previous Message | Віталій Тимчишин | 2012-07-11 08:23:01 | Re: Paged Query |