Re: The plan for FDW-based sharding
От | Joshua D. Drake |
---|---|
Тема | Re: The plan for FDW-based sharding |
Дата | |
Msg-id | 56D07D8A.8080801@commandprompt.com обсуждение исходный текст |
Ответ на | Re: The plan for FDW-based sharding (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: The plan for FDW-based sharding
|
Список | pgsql-hackers |
On 02/26/2016 08:06 AM, Robert Haas wrote: > On Fri, Feb 26, 2016 at 7:21 PM, Oleg Bartunov <obartunov@gmail.com> wrote: >> Right now tm is hardcoded and it's doesn't matter "if other people might >> need" at all. We at least provide developers ("other people") ability to >> work on their implementations and the patch is safe and doesn't sacrifices >> anything in core. > > I don't believe that. When we install APIs into core, we're > committing to keep those APIs around. And I think that we're far too > early in the development of transaction managers for PostgreSQL to > think that we know what APIs we want to commit to over the long term. Correct. [snip] > > Frankly, I'd like to see a GTM in core at some point because I'd like > everybody who uses PostgreSQL to have access to a GTM. What I don't > want is for every PostgreSQL company to develop its own GTM and > distribute it separately from everybody else's. IIUC, MySQL kinda did > that with storage engines and it resulted in the fragmentation of the > community. No it didn't. It allowed MySQL people to use the tool that best fit their needs. > We've had the same thing happen with replication tools - > every PostgreSQL company develops their own set. It would have been > better to have ONE set that was distributed by the core project so > that we didn't all do the same work over again. The reason people developed a bunch of external replication tools (and continue to) is because .Org has shown a unique lack of leadership in providing solutions for the problem. Historically speaking .Org was anti replication in core. It wasn't about who was going to be best. It was who was going to be best for what problem. The inclusion of the replication tools we have now speaks very loudly to the that lack of leadership. The moment .Org showed leadership and developed a reasonable solution to 80% of the problem, a great majority of people moved to hot standby and streaming replication. It is easy. It does not answer all the questions but it is default, in core and that gives people piece of mind. This is also why once PgLogical is up to -core quality and in -core, the great majority of people will work to dump Slony/Londiste/Insertproghere and use PgLogical. If .Org was interested in showing leadership in this area, a few hackers would get together with a few other hackers from XL and XC (although as I understand it XL is further along), have a few heart to heart, mind to mind meetings and determine: * Are either of these two solutions worth it?Yes? Then let's start working on an integration plan and get it done.No? Thenlet's start working on a .Org plan to solve that problem. But that likely won't happen because NIH. > > I don't understand the argument that without these hooks in core, > people can't continue to work on this. It isn't hard to work on GTM > without any core changes at all. You just patch your copy of > PostgreSQL. We do this all the time, for every patch. We don't add > hooks for every patch. > >> dtms. It's time to start working on dtm, I believe. The fact you don't >> think about distributed transactions support doesn't mean there no "other >> people", who has different ideas on postgres future. That's why we propose >> this patch, let's play the game ! > > I don't like to play games with the architecture of PostgreSQL. > Robert, this is all a game. It is a game of who wins the intellectual prize to whatever problem. Who gets the market or mind share and who gets to pretend they win the Oscar for coolest design. Sincerely, jD -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development. Everyone appreciates your honesty, until you are honest with them.
В списке pgsql-hackers по дате отправления:
Следующее
От: "Gabe F. Rudy"Дата:
Сообщение: Re: FDW handling count(*) through AnalyzeForeignTable or other constant time push-down