Christopher Browne wrote:
> Increasing the number of cache buffers _is_ likely to lead to some
> slowdowns:
>
> - Data that passes through the cache also passes through kernel
>cache, so it's recorded twice, and read twice...
Even worse, memory that's used for the PG cache is memory that's n
Christopher Browne wrote:
[EMAIL PROTECTED] (Josh Berkus) wrote:
This result is so surprising that I want people to take a look at it
and tell me if there's something wrong with the tests or some
bottlenecking factor that I've not seen.
I'm aware of two conspicuous scenarios where ARC would
Kevin Brown <[EMAIL PROTECTED]> writes:
> This is why I sometimes wonder whether or not it would be a win to use
> mmap() to access the data and index files --
mmap() is Right Out because it does not afford us sufficient control
over when changes to the in-memory data will propagate to disk. The
Tom Lane wrote:
> Kevin Brown <[EMAIL PROTECTED]> writes:
> > This is why I sometimes wonder whether or not it would be a win to use
> > mmap() to access the data and index files --
>
> mmap() is Right Out because it does not afford us sufficient control
> over when changes to the in-memory data
I wrote:
> That said, if it's typical for many changes to made to a page
> internally before PG needs to commit that page to disk, then your
> argument makes sense, and that's especially true if we simply cannot
> have the page written to disk in a partially-modified state (something
> I can easily
Kevin Brown <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> mmap() is Right Out because it does not afford us sufficient control
>> over when changes to the in-memory data will propagate to disk.
> ... that's especially true if we simply cannot
> have the page written to disk in a partially-modif
