Re: drop/truncate table sucks for large values of shared buffers

On 2015-06-27 10:10:04 -0400, Tom Lane wrote:
> In the past we've speculated about fixing the performance of these things
> by complicating the buffer lookup mechanism enough so that it could do
> "find any page for this table/tablespace/database" efficiently.
> Nobody's had ideas that seemed sane performance-wise though.

I've started to play around with doing that a year or three back. My
approach was to use a linux style radix tree for the buffer mapping
table.  Besides lack of time what made it hard to be efficient was the
size of our buffer tags requiring rather deep trees.

I think I was considering playing around with a two-level tree (so we
could cache a pointer in Relation or such), but the memory management
requirements for that made my head hurt too much. The other alternative
is to work on having a much simpler buffer tag

If you have a buffer mapping that allows orderly traversal it becomes a)
much easier to do efficient readahead, as it's possible to read uncached
areas b) allows to write combine neighbouring pages when writing out
from a backend.