Re: Minmax indexes

On Thu, Sep 26, 2013 at 2:58 PM, Jim Nasby <jim(at)nasby(dot)net> wrote:
> Why would we add additional code complexity when forks do the trick? That
> seems like a step backwards, not forward.

Well, they sorta do the trick, but see e.g. commit
ece01aae479227d9836294b287d872c5a6146a11. I doubt that's the only
code that's poorly-optimized for multiple forks; IOW, every time
someone adds a new fork, there's a system-wide cost to that, even if
that fork is only used in a tiny percentage of the relations that
exist in the system.

It's tempting to think that we can use the fork mechanism every time
we have multiple logical "streams" of blocks within a relation and
don't want to figure out a way to multiplex them onto the same
physical file. However, the reality is that the fork mechanism isn't
up to the job. I certainly don't want to imply that we shouldn't have
gone in that direction - both the fsm and the vm are huge steps
forward, and we wouldn't have gotten them in 8.4 without that
mechanism. But they haven't been entirely without their own pain,
too, and that pain is going to grow the more we push in the direction
of relying on forks.

> If the only complaint about forks is directory traversal why wouldn't we go
> with the well established practice of using multiple directories instead of
> glomming everything into one place?

That's not the only complaint about forks - but I support what you're
proposing there anyhow, because it will be helpful to users with lots
of relations regardless of what we do or do not decide to do about
forks.

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