Hi,
On 6/22/17 4:36 PM, Alexander Korotkov wrote:
> On Thu, Jun 22, 2017 at 5:27 PM, Robert Haas <robertmhaas@gmail.com
> <mailto:robertmhaas@gmail.com>> wrote:
>
> On Thu, Jun 22, 2017 at 8:32 AM, Alexander Korotkov
> <a.korotkov@postgrespro.ru <mailto:a.korotkov@postgrespro.ru>> wrote:
> > On Thu, Jun 22, 2017 at 4:01 AM, Michael Paquier <michael.paquier@gmail.com
<mailto: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.
I'd say that's one of the things we're trying to figure out in this
thread. Does it make sense to go with #1 in v1 of the patch, or do we
have to implement #2 or #3 to get some real benefit for the users?
>
> 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".
The question is "why" do you think that. What features do you expect
from pluggable storage API that would be impossible to implement with
option #1?
I'm not trying to be annoying or anything like that - I don't know the
answer and discussing those things is exactly why this thread exists.
I do agree #1 has limitations, and that it'd be great to get API that
supports all kinds of pluggable storage implementations. But I guess
that'll take some time.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services