Hi,
2012/2/27 Chris Travers <chris.travers@gmail.com> wrote:
>> 1. Buffering Pool
>>
>> To get rid of I/O bounds Mike proposes in-memory database structures.
...
>> Now I'm still wondering why PG could'nt realize that probably in
>> combination with unlogged tables? I don't overview the respective code
>> but I think it's worthwhile to discuss even if implementation of
>> memory-oriented structures would be to difficult.
>
>
> The reason is that the data structures assume disk-based data structures, so
> they are written to be efficient to look up on disk but not as efficient in
> memory.
That means, that this could be enhanced in PG.
Is there really no research or implementation projects going on in the
direction where all table content can be hold in-memory? This could be
enhanced in many ways (besides optimized in-memory structures)
including index-only scans.
> Note that VoltDB is a niche product and Stonebreaker makes this pretty
> clear. However, the more interesting question is what the tradeoffs are
> when looking at VoltDB vs Postgres-XC.
Ok, that's interesting too, looking at Postgres-XC (eXtensible
Cluster) is a multi-master write-scalable PostgreSQL cluster based on
shared-nothing architecture.
But I'm thinking more about enhancing PostgreSQL core.
VoltDB niche product? Look at his USENIX conferenc speech
(http://www.youtube.com/watch?v=uhDM4fcI2aI ) minute 11:53: There he
puts VoltDB into "high OLTP" and "old elephants" into category "low"
which only get the crevices and which have "The Innovators Dilemma".
My thesis is that PG doesn't have that problem necessarily because
it's open source and can be (and has been) refactored since then.
Yours, Stefan