Hello, Mr. Grittner,
From: "Kevin Grittner" <[EMAIL PROTECTED]>
> We have 3,000 "directly connected" users, various business partner
> interfaces, and public web entry doing OLTP in 72 databases
distributed
> around the state, with real-time replication to central databases
which
> are considered
"Kevin Grittner" <[EMAIL PROTECTED]> wrote:
> > I consider that smoothing the load (more meaningfully, response time)
> > has higher priority over checkpoint punctuality in a practical sense,
>
> I agree with that.
I agree with checkpoint_time is not so important, but we should
respect checkpo
>>> On Wed, Dec 20, 2006 at 6:05 AM, in message
<[EMAIL PROTECTED]>, "Takayuki Tsunakawa"
<[EMAIL PROTECTED]> wrote:
>
> I consider that smoothing the load (more meaningfully, response
time)
> has higher priority over checkpoint punctuality in a practical
sense,
> because the users of a system b
ITAGAKI Takahiro wrote:
> Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> > OK, if I understand correctly, instead of doing a buffer scan, write(),
> > and fsync(), and recyle the WAL files at checkpoint time, you delay the
> > scan/write part with the some delay.
>
> Exactly. Actual behavior of che
From: "ITAGAKI Takahiro" <[EMAIL PROTECTED]>
> Bruce Momjian <[EMAIL PROTECTED]> wrote:
>> Do you use the same delay autovacuum uses?
>
> What do you mean 'the same delay'? Autovacuum does VACUUM, not
CHECKPOINT.
> If you think cost-based-delay, I think we cannot use it here. It's
hard to
> estimat
Bruce Momjian <[EMAIL PROTECTED]> wrote:
> OK, if I understand correctly, instead of doing a buffer scan, write(),
> and fsync(), and recyle the WAL files at checkpoint time, you delay the
> scan/write part with the some delay.
Exactly. Actual behavior of checkpoint is not changed by the patch. C
