Horton

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

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: 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-19T11:15:18Z
Lists: pgsql-hackers 
Hi,

On 2018-12-19 12:02:38 +0100, Peter Eisentraut wrote:
> On 19/12/2018 11:15, Thomas Munro wrote:
> > It just means tuples stored in no particular order (as opposed to eg
> > btree tables, in systems that support those).
> 
> So would the proposed pluggable storage API allow index-organized base
> storage and other non-heap layouts?

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.

Greetings,

Andres Freund

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.