On Thu, Jun 22, 2017 at 8:32 AM, Alexander Korotkov <a.korotkov@postgrespro.ru> wrote: > On Thu, Jun 22, 2017 at 4:01 AM, Michael Paquier <michael.paquier@gmail.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.
What's your point? I assume that is what Michael meant.
TBH, I don't understand what particular enchantments do we expect from having #1.
This is why it's hard for me to say if #1 is good idea. It's also hard for me to say if patch upthread is right way of implementing #1.
But, I have gut feeling that if even #1 is good idea itself, it's definitely not what users expect from "pluggable storages".
From user side, it would be normal to expect that "pluggable storage" could be index-organized table where index could be say LSM...
------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
