Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance

* Claudio Freire (klaussfreire(at)gmail(dot)com) wrote:
> On Tue, Jan 14, 2014 at 2:17 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > I don't know either. I wasn't thinking so much that it would save CPU
> > time as that it would save memory. Consider a system with 32GB of
> > RAM. If you set shared_buffers=8GB, then in the worst case you've got
> > 25% of your RAM wasted storing pages that already exist, dirtied, in
> > shared_buffers. It's easy to imagine scenarios in which that results
> > in lots of extra I/O, so that the CPU required to do the accounting
> > comes to seem cheap by comparison.
>
> Not necessarily, you pay the CPU cost on each page fault (ie: first
> write to the buffer at least), each time the page checks into the
> shared buffers level.

I'm really not sure that this is a real issue for us, but if it is,
perhaps having this as an option for each read() call would work..?
That is to say, rather than have this be an open() flag or similar, it's
normal read() with a flags field where we could decide when we want
pages to be write-protected this way and when we don't (perhaps because
we know we're about to write to them).

I'm not 100% sure it'd be easy for us to manage that flag perfectly, but
it's our issue and it'd be on us to deal with as the kernel can't
possibly guess our intentions.

There were concerns brought up earlier that such a zero-copy-read option
wouldn't be performant though and I'm curious to hear more about those
and if we could avoid the performance issues by manging the
zero-copy-read case ourselves as Robert suggests.

Thanks,

Stephen