Re: Bgwriter strategies - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Bgwriter strategies
Date
Msg-id 25511.1184166992@sss.pgh.pa.us
Whole thread Raw
In response to Re: Bgwriter strategies  ("Pavan Deolasee" <pavan.deolasee@gmail.com>)
List pgsql-hackers
"Pavan Deolasee" <pavan.deolasee@gmail.com> writes:
> I think you are assuming that the next write of the same block won't
> use another OS cache block. I doubt if thats the way writes are handled
> by the kernel. Each write would typically end up being queued up in the
> kernel
> where each write will have its own copy of the block to the written. Isn't
> it ?

A kernel that worked like that would have a problem doing read(), ie,
it'd have to search to find the latest version of the block.  So I'd
expect that most systems would prefer to keep only one in-memory copy
of any given block and overwrite it at write() time.  No sane kernel
designer will optimize write() at the expense of read() performance,
especially when you consider that a design as above really pessimizes
write() too --- it does more I/O than is necessary when the same block
is modified repeatedly in a short time.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Chris Browne
Date:
Subject: Re: 2PC-induced lockup
Next
From: Andrew Sullivan
Date:
Subject: Re: 2PC-induced lockup