Re: Scaling shared buffer eviction

On Fri, Sep 26, 2014 at 8:26 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> Neither, really. The hash calculation is visible in the profile, but not
> that pronounced yet. The primary thing noticeable in profiles (besides
> cache efficiency) is the comparison of the full tag after locating a
> possible match in a bucket. 20 byte memcmp's aren't free.

Would it be faster to test the relfilenode first, and then test the
rest only if that matches?

One idea for improving this is to get rid of relation forks. Like all
true PostgreSQL patriots, I love the free space map and the visibility
map passionately, and I believe that those features are one of the
biggest contributors to the success of the project over the last
half-decade. But I'd love them even more if they didn't triple our
rate of inode consumption and bloat our buffer tags. More, it's just
not an extensible mechanism: too many things have to loop over all
forks, and it just doesn't scale to keep adding more of them. If we
added a metapage to each heap, we could have the FSM and VM have their
own relfilenode and just have the heap point at them. Or (maybe
better still) we could store the data in the heap itself.

It would be a lot of work, though. :-(

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