Re: heap metapages

* Simon Riggs (simon(at)2ndQuadrant(dot)com) wrote:
> The only thing against these ideas is that you're putting the design
> before the requirements, which always makes me nervous.
[...]
> What springs immediately to mind is why this would not be just another fork.

One of the requirements, though perhaps it wasn't made very clear,
really is to reduce the on-disk footprint, both in terms of inodes and
actual disk usage, if possible.

> This is important. I like the idea of breaking down the barriers
> between databases to allow it to be an option for one backend to
> access tables in multiple databases. The current mechanism doesn't
> actually prevent looking at data from other databases using internal
> APIs, so full security doesn't exist. It's a very common user
> requirement to wish to join tables stored in different databases,
> which ought to be possible more cleanly with correct privileges.

That's really a whole different ball of wax and I don't believe what
Robert was proposing would actually allow that to happen due to the
other database-level things which are needed to keep everything
consistent... That's my understanding, anyway. I'd be happy as anyone
if we could actually make it work, but isn't like the SysCache stuff per
database? Also, cross-database queries would actually make it more
difficult to have per-database roles, which is one thing that I was
hoping we might be able to work into this, though perhaps we could have
a shared roles table and a per-database roles table and only 'global'
roles would be able to issue cross-database queries..

> Not very sure why a metapage is better than a catalog table. We would
> still want a view that allows us to access that data as if it were a
> catalog table.

Right, we were discussing that, and what would happen if someone did a
'select *' against it... Having to pass through all of the files on
disk wouldn't be good, but if we could make it use a cache to return
that information, perhaps it'd work.

> Again, there are other ways to optimise the FSM for small tables.

Sure, but is there one where we also reduce the number of inodes we
allocate for tiny tables..?

> That sounds like the requirement that is driving this idea.

Regarding forensics, it's a nice bonus, but I think the real requirement
is the reduction of inode and disk usage, both for the per-database
catalog and for tiny tables.

> You don't have to rewrite the table, you just need to update the rows
> so they migrate to another block.

Well, that depends on exactly how it gets implemented, but that's an
interesting idea, certainly..

Thanks,

Stephen