Re: The plan for FDW-based sharding - Mailing list pgsql-hackers

From Konstantin Knizhnik
Subject Re: The plan for FDW-based sharding
Date
Msg-id 56D5CEEB.6030504@postgrespro.ru
Whole thread Raw
In response to Re: The plan for FDW-based sharding  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: The plan for FDW-based sharding  (Petr Jelinek <petr@2ndquadrant.com>)
List pgsql-hackers

On 01.03.2016 19:03, Robert Haas wrote:
> On Tue, Mar 1, 2016 at 10:37 AM, Bruce Momjian <bruce@momjian.us> wrote:
>> On Tue, Mar  1, 2016 at 10:19:45AM -0500, Robert Haas wrote:
>>>> Two reasons:
>>>> 1. There is no ideal implementation of DTM which will fit all possible needs
>>>> and be  efficient for all clusters.
>>> Hmm, what is the reasoning behind that statement?  I mean, it is
>>> certainly true that there are some places where we have decided that
>>> one-size-fits-all is not the right approach.  Indexing, for example.
>> Uh, is that even true of indexing?  While the plug-in nature of indexing
>> allows for easier development and testing, does anyone create plug-in
>> indexing that isn't shipped by us?  I thought WAL support was something
>> that prevented external indexing solutions from working.
> True.  There is an API, though, and having pluggable WAL support seems
> desirable too.  At the same time, I don't think we know of anyone
> maintaining a non-core index AM ... and there are probably good
> reasons for that.  We end up revising the index AM API pretty
> regularly every time somebody wants to do something new, so it's not
> really a stable API that extensions can just tap into.  I suspect that
> a transaction manager API would end up similarly situated.
>

IMHO non-stable API is better than lack of API.
Just because it makes it possible to implement features in modular way.
And refactoring of API is not so difficult thing...


-- 
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company




pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Confusing with commit time usage in logical decoding
Next
From: Robert Haas
Date:
Subject: Re: GetExistingLocalJoinPath() vs. the docs