Robert Haas <robertmh...@gmail.com> writes:
> On Tue, May 22, 2012 at 10:25 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> My own thoughts about this had pointed in the direction of getting rid
>> of the central freelist entirely, instead letting each backend run its
>> own independent clock sweep as needed.
> Hmm, that's certainly an interesting idea. I fear that if the clock
> sweeps from the different backends ended up too closely synchronized,
> you would end up evicting whatever was in the way, be it hot or cold.
> It might almost be better to have individual backends choose buffers
> to evict at random; if the chosen buffer isn't evictable, we decrement
> its usage count and pick another one, also at random.
Hmm ... yeah, in principle that could be better. It's still a clock
sweep but following a hard-to-predict ordering of the buffers. Being
hard to predict doesn't necessarily guarantee no bad behavior though.
Maybe we could do something a bit cheaper than random() and more
amenable to analysis, that would still ensure that backends couldn't end
up with closely sync'd scans. I'm imagining advancing not 1 buffer
each time, but K buffers where each backend will use a different value
of K. Perhaps backend with backendID N could use the N'th prime number,
say. You'd want something relatively prime to shared_buffers to
guarantee that the backend can visit all the buffers, and just making it
prime would do fine.
> With respect to the control logic for the background writer, one idea
> I had was to get rid of the idea that the background writer's job is
> to write in advance of the strategy point. Instead, every time the
> clock sweep passes over a dirty buffer that is otherwise evictable, we
> add it to a queue of things that the bgwriter should clean. Those
> buffers, once cleaned, go on the free list. Maybe some variant of
> that could work with your idea.
Both ends of that imply centralized data structures that could become
contention bottlenecks, so it doesn't sound tremendously appealing to
me. Maybe it can work as long as nobody has to lock the lists for long,
but I'd rather think of approaches with no central point of contention.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
