On 2014-09-26 09:59:41 -0400, Robert Haas wrote:
> On Fri, Sep 26, 2014 at 8:26 AM, Andres Freund <andres@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?
I tried that and I couldn't see that much benefit. Check my message to
Heikki.
> One idea for improving this is to get rid of relation forks.
I think that's the hardest end to start from. A cool goal, but
hard. Getting rid of the tablespace sound comparatively simple. And even
getting rid of the database in the buffer tag seems to be simpler
although already pretty hard.
> 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. :-(
Yea, it's really hard. And nearly impossible to do without breaking
binary compatibility.
What I've been wondering about was to give individual forks their own
relfilenodes and manage them via columns in pg_class. But that's also a
heck of a lot of work and gets complicated for unlogged relations
because we need to access those during recovery when we don't have
catalog access yet and can't access all databases anyway.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
