Re: Detrimental performance impact of ringbuffers on performance - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Detrimental performance impact of ringbuffers on performance
Date
Msg-id 20160413152748.ufkqzkk3slmtcddo@alap3.anarazel.de
Whole thread Raw
In response to Re: Detrimental performance impact of ringbuffers on performance  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 2016-04-13 06:57:15 -0400, Robert Haas wrote:
> You will eventually, because each scan will pick a new ring buffer,
> and gradually more and more of the relation will get cached.  But it
> can take a while.

You really don't need much new data to make that an unobtainable goal
... :/


> I'd be more inclined to try to fix this by prewarming the buffers that
> were in shared_buffers at shutdown.

That doesn't solve the problem of not reacting to actual new data? It's
not that uncommon to regularly load new data with copy and drop old
partitions, just to keep the workload memory resident...

Andres



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <
Next
From: Tom Lane
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <