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

On Sat, Jun 27, 2015 at 11:38 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> 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

Wouldn't even a two-level tree have the same problem you complained
about vis-a-vis chash? In that case, you were of the opinion that
even ONE extra level of indirection was enough to pinch. (I'm still
hoping there is a way to fix that, but even so.)

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company