Subject: Re: Pluggable storage
To: pgsql-hackers@postgresql.org
References: <20160824182201.GA232997@alvherre.pgsql>
 <20161013202642.ksiuyx72gu6wgupf@alvherre.pgsql>
 <CAJrrPGfG7BarSFb6KQkOOYVaC6vjQRgG45+J2+TwLHHaFKuwGA@mail.gmail.com>
 <CA+TgmoYQN9xtMopr4Db3UFCqpbfd5DJb0j5apSmWtkyuWRz0Xw@mail.gmail.com>
 <CAB7nPqR6TorHQ_mXmAiB_cL40Vf2+F6hsue-P9HVGoxVxoHyKA@mail.gmail.com>
 <CAPpHfdsSAyeRHd6Z_n=dNv0WbUeW5eYD0rDN3xeqO+8Q_H4uaw@mail.gmail.com>
 <CA+Tgmoaja-kynqWWt9j3BhtRUhK3d_NmdhztAApAfG7Ox5UEYQ@mail.gmail.com>
 <CAPpHfdty4V3XnKTpHA9ZKyh4MGbSqp8WyQh=pep4FWuBUOtGKA@mail.gmail.com>
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Message-ID: <0562d142-a0b0-e1ba-a535-fcf02fa51566@2ndquadrant.com>
Date: Thu, 22 Jun 2017 23:36:27 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101
 Thunderbird/54.0a2
MIME-Version: 1.0
In-Reply-To: 
 <CAPpHfdty4V3XnKTpHA9ZKyh4MGbSqp8WyQh=pep4FWuBUOtGKA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers