Re: Database block lifecycle

On Tuesday, August 12, 2014, pinker <pinker(at)onet(dot)eu> wrote:

> Yesterday I had an interesting discussion with my colleague about shared
> buffers size for our new server. This machine (is dedicated for db) has got
> 512GB of RAM and database size is about 80GB, so he assumes that db will
> never have to read from disk,

Do you ever plan on restarting this server? Doing maintenance? Applying
security patches?

> so there is no point to adjust read ahead
> setting, because every block gonna be read from RAM. As I've red in Greg
> Smith book, once a block is changed it will be written to a disk and
> buffers
> page is marked as clean, which would mean than changes occur in the same
> page as before? What if dirty page doesn't have enough space for another
> row
> and row has to be written to another page? Is it still occurs in RAM? If
> that's true all updates of FSM occurs in RAM as well?
>

None of that still should need to read from disk regularly once the
database is warmed up.

>
> What about buffers_clean and pg_clog then? Are those maintained completely
> in RAM as well without direct read from disk at all?
>
> To be precise, does the path to update and read updated row looks like a or
> b?:
> a). clean page (shared buffers) -> dirty page (shared buffers) -> to disk
> ->
> read from disk -> shared buffers -> query
> b). clean page (shared buffers) -> dirty page (shared buffers) -> to disk
> & dirty page (shared buffers) -> clean page (shared buffers) -> query
>

More like b), but you are missing all the states that involve "clean in
shared_buffers, dirty in FS cache" and such.

>
> btw. 512MB if we assume up to 600 connection is a reasonable value?
>

Reasonable value for what?

Cheers,

Jeff