I recently had a chat with someone who was pretty intimate with Adabas
for a number of years who's in the process of figuring things out
about PostgreSQL. We poked at bits of the respective implementations,
seeing some similarities and differences. He pointed out one aspect
of index handling that could (in principle) be an interesting
optimization.
Evidently, in Adabas, index leaf nodes were not simply tuples, but
lists where the index value would not be repeated.
In PostgreSQL, if you have the index value 'abc', and there are 10
tuples with that value, then you'll have a page full of tuples of the
following form:
|abc|ptr[rec1]|abc|ptr[rec2]|abc|ptr[rec3]| ...and so forth...
Now, the Adabas approach was rather different. It would only have the
index value once, and then have the list of tuple pointers:
|abc|ptr[rec1],ptr[rec2],ptr[rec3],...[ptr[rec10]|
This could allow a fair bit of compression, for cases where the index
value is not unique.
There is a concommitant downside, that concurrent updates may fight
over a page, and, since there would be a higher density, there would
be more need to fight over pages.
Does this seem pretty much like madness? Or is it a plausible "some
day ToDo"?
--
"cbbrowne","@","acm.org"
http://linuxfinances.info/info/postgresql.html
"I don't do drugs anymore 'cause I find I get the same effect just by
standing up really fast." -- Jonathan Katz
