Re: What to name the current heap after pluggable storage / what to rename?

David Fetter <david@fetter.org>

From: David Fetter <david@fetter.org>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Andres Freund <andres@anarazel.de>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Thomas Munro <thomas.munro@enterprisedb.com>, Arkhena@gmail.com, Pg Hackers <pgsql-hackers@postgresql.org>, Haribabu Kommi <kommi.haribabu@gmail.com>, Alexander Korotkov <a.korotkov@postgrespro.ru>, Robert Haas <robertmhaas@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>
Date: 2018-12-19T19:08:03Z
Lists: pgsql-hackers
On Wed, Dec 19, 2018 at 08:32:28AM -0300, Alvaro Herrera wrote:
> 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".

oheap for "original?"

Best,
David.
-- 
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate


Commits

  1. Replace heapam.h includes with {table, relation}.h where applicable.

  2. Replace uses of heap_open et al with the corresponding table_* function.

  3. Introduce access/{table.h, relation.h}, for generic functions from heapam.h.