From: | Petr Jelinek <petr(at)2ndquadrant(dot)com> |
---|---|
To: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: The plan for FDW-based sharding |
Date: | 2016-03-01 18:19:13 |
Message-ID: | 56D5DD21.3040604@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 01/03/16 18:18, Konstantin Knizhnik wrote:
>
> On 01.03.2016 19:03, Robert Haas wrote:
>> On Tue, Mar 1, 2016 at 10:37 AM, Bruce Momjian <bruce(at)momjian(dot)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...
>
Since this thread heavily discusses the XTM, I have question about the
XTM as proposed because one thing is very unclear to me - what happens
when user changes the XTM plugin on the server? I didn't see any xid
handover API which makes me wonder if changes of a plugin (or for
example failure to load previously used plugin due to admin error) will
send server to similar situation as xid wraparound.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-03-01 18:20:43 | Re: A trivial fix on extensiblenode |
Previous Message | Robert Haas | 2016-03-01 18:10:41 | Re: extend pgbench expressions with functions |