| From: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
|---|---|
| To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Pluggable storage |
| Date: | 2017-06-22 12:32:00 |
| Message-ID: | CAPpHfdsSAyeRHd6Z_n=dNv0WbUeW5eYD0rDN3xeqO+8Q_H4uaw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jun 22, 2017 at 4:01 AM, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
wrote:
> Putting that in a couple of words.
> 1. Table AM with a 6-byte TID.
> 2. Table AM with a custom locator format, which could be TID-like.
> 3. Table AM with no locators.
>
> Getting into having #1 first to work out would already be really
> useful for users.
What exactly would be useful for *users*? Any kind of API itself is
completely useless for users, because they are users, not developers.
Storage API could be useful for developers to implement storage AMs whose
in turn could be useful for users. Then while saying that #1 is useful for
users, it would be nice to keep in mind particular storage AMs which can be
implemented using #1.
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Korotkov | 2017-06-22 12:35:13 | Re: TRUE and true |
| Previous Message | Alexander Korotkov | 2017-06-22 12:16:21 | Re: Pluggable storage |