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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
