Hi,
On 2018-Dec-19, Andres Freund wrote:
> Well, that depends on what "non-heap layouts" you're thinking of. I
> think there'd be some further work needed to make efficient IOTs
> possible, but the patchset gets us a long way to be able to do that in a
> pluggable fashion. Biggest problem would probably be extending the
> existing index AMs, for secondary indexes, to point to a key wider than
> a tid, without loosing too much efficiency.
I think the important question is will we eventually get the option to
do "CREATE TABLE ... STORAGE indexorg" (or whatever name) rather than
are we already getting that feature, and I think the answer is clearly
yes, so we should keep using the word "heap" in the name as the primary
feature of the historical implementation.
The "zheap" name makes it clear that it is still a heap; the main
difference (if I understand correctly) is how does tuple
updating/deletion work.
The current heap implementation is for "non-overwriting storage
management", but that's a mouthful and acronyms based on
"non-overwriting" don't seem great ("noheap" seems a bit silly. Maybe
"nowheap" is better? How about "nosheap"?)
Maybe we can take the easy way and use something like "stdheap".
Or just "nheap".
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services