| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
| Cc: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Arkhena(at)gmail(dot)com, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Robert Haas <robertmhaas(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Subject: | Re: What to name the current heap after pluggable storage / what to rename? |
| Date: | 2018-12-19 11:15:18 |
| Message-ID: | 20181219111518.sogij7brkh6iennh@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2018-12-19 11:32:28 | Re: What to name the current heap after pluggable storage / what to rename? |
| Previous Message | Alvaro Herrera | 2018-12-19 11:14:59 | Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query |