From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: pgsql-hackers@postgresql.org
Subject: Re: Pluggable storage
Date: Thu, 22 Jun 2017 23:36:27 +0200
Message-ID: <0562d142-a0b0-e1ba-a535-fcf02fa51566@2ndquadrant.com> (raw)
In-Reply-To: <CAPpHfdty4V3XnKTpHA9ZKyh4MGbSqp8WyQh=pep4FWuBUOtGKA@mail.gmail.com>
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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tomas.vondra@2ndquadrant.com
Subject: Re: Pluggable storage
In-Reply-To: <0562d142-a0b0-e1ba-a535-fcf02fa51566@2ndquadrant.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox