Re: hanging for 30sec when checkpointing - Mailing list pgsql-admin

From Shane Wright
Subject Re: hanging for 30sec when checkpointing
Date
Msg-id 9BB17A7C-58C7-11D8-918E-000393A5890E@shanewright.co.uk
Whole thread Raw
In response to Re: hanging for 30sec when checkpointing  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: hanging for 30sec when checkpointing
List pgsql-admin
Tom,


Damn, why didn't I think of that myself...


Although, is there any performance implication of not doing
checkpoints very often?  (aside from, I assume, that each checkpoint
will take longer and hence saturate available I/O for longer)


Cheers


Shane


On 6 Feb 2004, at 15:33, Tom Lane wrote:


<excerpt>Shane Wright <<me@shanewright.co.uk> writes:

<excerpt>Hmm that gives me an idea, for bulk processing, is there a
way of

detecting from a client when a checkpoint is about to happen so it can

wait until it's finished?

</excerpt>

No, but maybe you could think about scheduling checkpoints yourself

to not coincide with your bulk jobs.  You could issue CHECKPOINT

commands from cron or whatever is dispatching your bulk jobs, and then

widen the checkpoint-timing parameters in postgresql.conf enough to

avoid automatic CHECKPOINTs.


The only real drawback of less-frequent CHECKPOINTs is that the amount

of WAL space required goes up proportionally.  (Oh, and it might take

proportionally longer to recover after a crash, too.)


            regards, tom lane



</excerpt><fontfamily><param>Arial</param><smaller>Shane Wright

Technical Manager

eDigitalResearch.com

2 Berrywood Business Village

Hedge End

Hampshire

SO30 2UN

T +44 (0) 1489 772920

F +44 (0) 1489 772922

 

This message is sent in confidence for the addressee only.  The
contents are not to be disclosed to anyone other than the addressee. 
Unauthorised recipients must preserve this confidentiality and should
please advise the sender immediately of any error in transmission.

 

Any attachment(s) to this message has been checked for viruses, but
please rely on your own virus checker and procedures.</smaller></fontfamily>

Tom,

Damn, why didn't I think of that myself...

Although, is there any performance implication of not doing checkpoints
very often?  (aside from, I assume, that each checkpoint will take
longer and hence saturate available I/O for longer)

Cheers

Shane

On 6 Feb 2004, at 15:33, Tom Lane wrote:

> Shane Wright <me@shanewright.co.uk> writes:
>> Hmm that gives me an idea, for bulk processing, is there a way of
>> detecting from a client when a checkpoint is about to happen so it can
>> wait until it's finished?
>
> No, but maybe you could think about scheduling checkpoints yourself
> to not coincide with your bulk jobs.  You could issue CHECKPOINT
> commands from cron or whatever is dispatching your bulk jobs, and then
> widen the checkpoint-timing parameters in postgresql.conf enough to
> avoid automatic CHECKPOINTs.
>
> The only real drawback of less-frequent CHECKPOINTs is that the amount
> of WAL space required goes up proportionally.  (Oh, and it might take
> proportionally longer to recover after a crash, too.)
>
>             regards, tom lane
>
>
Shane Wright
Technical Manager
eDigitalResearch.com
2 Berrywood Business Village
Hedge End
Hampshire
SO30 2UN
T +44 (0) 1489 772920
F +44 (0) 1489 772922
 
This message is sent in confidence for the addressee only.  The
contents are not to be disclosed to anyone other than the addressee. 
Unauthorised recipients must preserve this confidentiality and should
please advise the sender immediately of any error in transmission.
 
Any attachment(s) to this message has been checked for viruses, but
please rely on your own virus checker and procedures.

pgsql-admin by date:

Previous
From: hal
Date:
Subject: HELP: optimizing shared mem
Next
From: kaolin fire
Date:
Subject: FATAL 2: (pg_clog ... no such file or directory)