Re: The plan for FDW-based sharding
От | Konstantin Knizhnik |
---|---|
Тема | Re: The plan for FDW-based sharding |
Дата | |
Msg-id | 56D5CEEB.6030504@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: The plan for FDW-based sharding (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: The plan for FDW-based sharding
|
Список | 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 по дате отправления: