On 8/9/12 10:56 AM, Jameison Martin wrote:
> [separate topic: pluggable heap manager]
> I'm quite interested in pursuing more aggressive compression strategies, and I'd like to do so in the context of the
heapmanager. I'm exploring having a pluggable heap manager implementation and would be interested in feedback on that
asa general approach. My thinking is that I'd like to be able to have PostgreSQL support multiple heap implementations
alongthe lines of how multiple index types are supported, though probably only the existing heap manager implementation
wouldbe part of the actual codeline. I've done a little exploratory work of looking at the heap interface. I was
planningon doing a little prototyping before suggesting anything concrete, but, assuming the concept of a layered heap
manageris not inherently objectionable, I was thinking of cleaning up the heap interface a little (e.g. some HOT stuff
hasbled across a little), then taking a whack at formalizing the interface along the lines of the index layering. So
ideallyI'd make a few separate
> submissions and if all goes according to plan I'd be able to have a pluggable heap manager implementation that I
couldwork on independently and which could in theory use the same hooks as the existing heap implementation. And if it
turnsout that my implementation is deemed to be general enough it could be released to the community.
I'm definitely interested in things that can shrink our working-set-size; things that others might not be keen on.
(Likehaving the on-disk format be tighter than the in-memory one). Having the ability to put in different heap storage
couldbe a good way to accommodate that. Especially if you could change it on a per-table basis.
--
Jim C. Nasby, Database Architect jim@nasby.net
512.569.9461 (cell) http://jim.nasby.net