On Sat, Jun 27, 2015 at 11:38 AM, Andres Freund <and...@anarazel.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
