public inbox for [email protected]  

help / color / mirror / Atom feed

From: Andreas Karlsson <[email protected]>
To: Nitin Jadhav <[email protected]>
To: Tristan Partin <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Matthias van de Meent <[email protected]>
Cc: Heikki Linnakangas <[email protected]>
Cc: Andres Freund <[email protected]>
Subject: Re: Extensible storage manager API - SMGR hook Redux
Date: Mon, 3 Feb 2025 13:41:15 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAMm1aWakiMa1LK6NQN8BG-mamBhpTaoOOZwV3DhHyQ3ZtDeFAA@mail.gmail.com>
References: <CAEze2WgMySu2suO_TLvFyGY3URa4mAx22WeoEicnK=PCNWEMrA@mail.gmail.com>
	<[email protected]>
	<CAMm1aWakiMa1LK6NQN8BG-mamBhpTaoOOZwV3DhHyQ3ZtDeFAA@mail.gmail.com>

On 9/21/24 8:24 PM, Nitin Jadhav wrote:
> I reviewed the discussion and took a look at the patch sets. It seems
> like many things are combined here. Based on the subject, I initially
> thought it aimed to provide the infrastructure to easily extend
> storage managers. This would allow anyone to create their own storage
> managers using this infrastructure. While it addresses this, it also
> includes additional features like fsync_checker, which I believe
> should be a separate feature. Even though it might use the same
> infrastructure, it appears to be a different functionality. I think we
> should focus solely on providing the infrastructure here.

I personally think that it is fine that there are patches which provide 
a PoC implementation of the new API. It is hard to verify if an API is 
correct if there are zero alternative implementations. And there is also 
a case to be made for having one of them in contrib just to make it hard 
for us to break the API for external users.

That said I have not made up my mind yet if this is a good extension for 
contrib.

> We need to decide on our approach—whether to use a hook-based method
> or a registration-based method—and I believe this requires further
> discussion.

100% agreed.

> The hook-based approach is simple and works well for anyone writing
> their own storage manager. However, it has its limitations as we can
> either use the default storage manager or a custom-built one for all
> the work load, but we cannot choose between multiple storage managers.
> On the other hand, the registration-based approach allows choosing
> between multiple storage managers based on the workload, though it
> requires a lot of changes.
> 
> Are we planning to support other storage managers in PostgreSQL in the
> near future? If not, it is better to go with the hook-based approach.
> Otherwise, the registration-based approach is preferable as it offers
> more flexibility to users and enhances PostgreSQL’s functionality.
> 
> Could you please share your thoughts on this? Also, let me know if
> this topic has already been discussed and if any conclusions were
> reached.

I do not think there is any plan for core to support multiple storage 
managers, but there are open source thrid party extensions which plan to 
implement this API once it has been merged.

Andreas

view thread (5+ messages)  latest in thread

reply

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: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Extensible storage manager API - SMGR hook Redux
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox