On Tue, Jan 21, 2014 at 5:01 PM, Миша Тюрин wrote:
> And does anyone know how mysql-innodb guys are getting with similar issues?
I'm no innodb dev, but from managing mysql databases, I can say that
mysql simply eats all the RAM the admin is willing to allocate for the
DB, and is content with the
Hi
But maybe postgres should provide its own subsystem like linux active/inactive
memory over and/or near shared buffers? There
could be some postgres special heuristics in its own approach.
And does anyone know how mysql-innodb guys are getting with similar issues?
Thank you!
On Fri, Jan 17, 2014 at 04:31:48PM +, Mel Gorman wrote:
> NUMA Optimisations
> --
>
> The primary one that showed up was zone_reclaim_mode. Enabling that parameter
> is a disaster for many workloads and apparently Postgres is one. It might
> be time to revisit leaving that thin
On 2014-01-17 16:18:49 -0800, Greg Stark wrote:
> On Fri, Jan 17, 2014 at 9:14 AM, Andres Freund wrote:
> > The scheme that'd allow us is the following:
> > When postgres reads a data page, it will continue to first look up the
> > page in its shared buffers, if it's not there, it will perform a p
On Fri, Jan 17, 2014 at 9:14 AM, Andres Freund wrote:
> The scheme that'd allow us is the following:
> When postgres reads a data page, it will continue to first look up the
> page in its shared buffers, if it's not there, it will perform a page
> cache backed read, but instruct that read to immed
Hi Mel,
On 2014-01-17 16:31:48 +, Mel Gorman wrote:
> Direct IO, buffered IO, double buffering and wishlists
> --
>3. Hint that a page should be dropped immediately when IO completes.
> There is already something like this buried in
On Wed, Jan 15, 2014 at 02:14:08PM +, Mel Gorman wrote:
> > One assumption would be that Postgres is perfectly happy with the current
> > kernel behaviour in which case our discussion here is done.
>
> It has been demonstrated that this statement was farcical. The thread is
> massive just fro
