On Fri, Sep 26, 2014 at 8:26 AM, Andres Freund <and...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
