Re: proposal: adding a GUC for BAS_BULKREAD strategy

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: didier <did447(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: adding a GUC for BAS_BULKREAD strategy
Date: 2014-09-23 12:55:52
Message-ID: 20140923125552.GA3604@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2014-09-23 14:47:33 +0200, didier wrote:
> Currently the value is hard code to NBuffers / 4 but ISTM that with
> bigger shared_buffer it's too much, ie even with a DB 10 to 20 time
> the memory size there's a lot of tables under this limit and nightly
> batch reports are trashing the shared buffers cache as if there's no
> tomorrow.

I'd like the ability to tune this as well. Even though I more often want
to entirely disable it, rather than make it more aggressive. For
workloads where the majority of the read data fits into shared_buffers
and sequential scans over large relations are something happening
frequently, the current strategy *sucks* because the large table will
pretty much never get cached.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-09-23 13:00:17 Re: RLS feature has been committed
Previous Message didier 2014-09-23 12:47:33 proposal: adding a GUC for BAS_BULKREAD strategy