great thanks for the help and explanation, I will start logging the
information you mentioned and do some analysis.
On Tue, Jul 10, 2012 at 10:46 AM, Craig Ringer wrote:
> On 07/10/2012 10:25 AM, Yan Chunlu wrote:
>
> I didn't set log_min_duration_statement in the postgresql.con
the **"SET
log_min_duration_statement to 30" I could turn the log off within my
application.*
On Tue, Jul 10, 2012 at 9:25 AM, Craig Ringer wrote:
> On 07/09/2012 05:20 PM, Yan Chunlu wrote:
>
>>
>> the value of "log_min_messages" in postgresql.conf is er
knew that select could cause writes, but not at this magnitude
On Fri, Jul 13, 2012 at 2:53 AM, Jeff Janes wrote:
> On Thu, Jul 12, 2012 at 9:07 AM, Ants Aasma wrote:
> > On Thu, Jul 12, 2012 at 3:48 PM, Yan Chunlu
> wrote:
> >> yes the system seems overloaded, I a
65.10 12.421.86 4.39 13.60
sdb 0.00 0.000.000.00 0.00 0.00 0.00
0.00 0.00 0.000.00 0.00 0.00
On Thu, Jul 12, 2012 at 2:56 PM, Craig Ringer wrote:
> On 07/12/2012 01:10 PM, Yan Chunlu wrote:
>
> after check out the wik
slow
and block.
I guess I should optimized those queries first...
On Thu, Jul 12, 2012 at 10:20 AM, Craig Ringer wrote:
> On 07/12/2012 08:47 AM, Yan Chunlu wrote:
>
> Really sorry for the lack of information
>
> I shouldn't have grumped like that either, sorry about
wrote:
> On 07/11/2012 07:40 PM, Yan Chunlu wrote:
>
> could that because of my system is really busy?
> 1, postgresql always have 400+ connections(dozens of python process using
> client pool)
> 2, the query peak is 50+/s
> 3, I do have some bad performance sql executing per
slow query log, is there anything like "explain analyze" that shows
specific information about IO usage?
On Wed, Jul 11, 2012 at 7:59 PM, Ants Aasma wrote:
> On Wed, Jul 11, 2012 at 9:24 AM, Yan Chunlu wrote:
> > I have logged one day data and found the checkpoint is rather
others?
because when I execute those simple sql directly, they was fast. but the
slow query log shows it took too much time.
On Wed, Jul 11, 2012 at 4:23 PM, Albe Laurenz wrote:
> Yan Chunlu wrote:
> > I have logged one day data and found the checkpoint is rather
> frequently(detai
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?
or the slow query is about something else? thanks!
On Tue, Jul 10, 2012 at 10:46 AM, Craig Ringer wrote:
> On 07/10/2012 10:25 AM, Yan Chu
COMMIT
but only one "BEGIN" in the same one day log file, did that influence the
query time too?
On Fri, Jul 6, 2012 at 9:10 PM, Albe Laurenz wrote:
> Yan Chunlu wrote:
> > I have grabbed one day slow query log and analyzed it by pgfouine, to
> my surprise, the slowest q
I have grabbed one day slow query log and analyzed it by pgfouine, to my
surprise, the slowest query is just a simple select statement:
*select diggcontent_data_message.thing_id, diggcontent_data_message.KEY,
diggcontent_data_message.value, diggcontent_data_message.kind FROM
diggcontent_data_messa
11 matches
Mail list logo
