James Rogers <jamesr@best.com> writes:
> Now, I've actually hacked commercial MVCC engines back in the day, and am
> comfortable playing around in database internals. I have an "itch to
> scratch" for improving the scalability of Really Large Tables by explicitly
> allowing control of table layouts as an optional property of the tables. I
> would like some feedback as to whether this is practical given the current
> architecture; it appears that it is, but I'm not intimately familiar with it
I think you'd need to do some basic architectural work first. Right now
we have a clean API for index access methods, but there is no comparable
abstraction layer for heaps (tables). It'd probably be necessary to
create such a layer in order to allow different heap organizations to be
supported. Another point of confusion is that heaps and indexes are
rigidly distinct. Perhaps some heaps could be considered to be indexes
as well, in order to support your idea of b-tree-organized tables.
Doing that would undoubtedly break a few places though.
> Both of these things really are attempts to address the same basic problem,
> which is optimizing the number of buffers a given query uses by making the
> tables layout reflect typical queries.
Hm, are you sure that smarter buffer management wouldn't serve the
purpose?
regards, tom lane
