On Wed, Feb 05, 2020 at 08:00:26PM -0800, Andres Freund wrote:
> I think it would make sense to have seqscan_ringbuffer_threshold,
> {bulkread,bulkwrite,vacuum}_ringbuffer_size.
I suggest the possibility of somehow forcing a ringbuffer for nonbulk writes
for the current session.
In our use-case,
On Thu, Feb 6, 2020 at 1:52 PM Andres Freund wrote:
> I admit it's awkward. I think we possibly could still just make the size
> displayed in bytes in either case, reducing that issue a *bit*?
That seems like it makes it even more confusing, honestly.
> > It'd sort of be nicer to have two
Hi,
On 2020-02-06 13:15:04 -0500, Robert Haas wrote:
> On Wed, Feb 5, 2020 at 11:00 PM Andres Freund wrote:
> > I.e. to maintain the current defaults, seqscan_ringbuffer_threshold
> > would be -4.0, but could be also be set to an absolute 4GB (converted to
> > pages). Probably would want a GUC
On Wed, Feb 5, 2020 at 11:00 PM Andres Freund wrote:
> I.e. to maintain the current defaults, seqscan_ringbuffer_threshold
> would be -4.0, but could be also be set to an absolute 4GB (converted to
> pages). Probably would want a GUC show function that displays
> proportional values in a nice
Hi,
On 2020-02-06 07:18:00 +0100, Laurenz Albe wrote:
> On Wed, 2020-02-05 at 20:00 -0800, Andres Freund wrote:
> > The ringbuffers we use for seqscans, vacuum, copy etc can cause very
> > drastic slowdowns (see e.g. [1]), an can cause some workloads to
> > practically never end up utilizing
On Wed, 2020-02-05 at 20:00 -0800, Andres Freund wrote:
> The ringbuffers we use for seqscans, vacuum, copy etc can cause very
> drastic slowdowns (see e.g. [1]), an can cause some workloads to
> practically never end up utilizing shared buffers. ETL workloads
> e.g. regularly fight with that
Hi,
On 2020-02-06 05:12:11 +, tsunakawa.ta...@fujitsu.com wrote:
> I think per-table reloption is necessary as well as or instead of GUC,
> because the need for caching depends on the table (see below for Oracle's
> manual.)
I'm inclined to not do that initially. It's going to be
From: Andres Freund
> While I think there's a number of improvements[2] we could make to the
> ringbuffer logic, I think we should also just allow to make them
> configurable. I think that'll allow a decent number of systems perform
> better (especially on slightly bigger systems the the current
Hi,
The ringbuffers we use for seqscans, vacuum, copy etc can cause very
drastic slowdowns (see e.g. [1]), an can cause some workloads to
practically never end up utilizing shared buffers. ETL workloads
e.g. regularly fight with that problem.
While I think there's a number of improvements[2] we
