On Wed, Feb 24, 2016 at 01:02:21PM -0300, Alvaro Herrera wrote: > Bruce Momjian wrote: > > On Wed, Feb 24, 2016 at 01:08:29AM +0000, Simon Riggs wrote: > > > > It's never been our policy to try to include major projects in single code > > > drops. Any move of XL/XC code into PostgreSQL core would need to be done > > > piece > > > by piece across many releases. XL is definitely too big for the elephant > > > to eat > > > in one mouthful. > > > > Is there any plan to move the XL/XC code into Postgres? If so, I have > > not heard of it. I thought everyone agreed it was too much code change, > > which is why it is a separate code tree. Is that incorrect? > > Yes, I think that's incorrect. > > What was said, as I understood it, is that Postgres-XL is too big to > merge in a single commit -- just like merging BDR would have been. > Indulge me while I make a parallel with BDR for a bit. > 2ndQuadrant never pushed for merging BDR in a single commit; what was > done was to split it, and propose individual pieces for commit. Many of > these pieces are now already committed (event triggers, background > workers, logical decoding, replication slots, and many others). The > "BDR patch" is now much smaller, and it's quite possible that we will > see it merged someday. Will it be different from what it was when the > BDR project started, all those years ago? You bet. Having the > prototype BDR initially was what allowed the whole plan to make sense, > because it showed that the pieces interacted in the right ways to make > it work as a whole.
Yes, that is my understanding too. > (I'm not saying 2ndQuadrant is so wise to do things this way. I'm > pretty sure you can see the same thing in parallel query development, > for instance.) > > In the same way, Postgres-XL is far too big to merge in a single commit. > But that doesn't mean it will never be merged. What is more likely to > happen instead is that some pieces of it are going to be submitted > separately for consideration. It is a slow process, but progress is > real and tangible. We know this process will yield a useful outcome, I was not aware there was any process to merge XC/XL into Postgres, at least from the XC/XL side. I know there is desire to take code from XC/XL on the FDW-sharding side. I think the most conservative merge approach is to try to enhance existing Postgres features first (FDWs, partitioning, parallelism), perhaps features that didn't exist at the time XC/XL were designed. If they work, keep them and add the XC/XL-specific parts. If the enhance-features approach doesn't work, we then have to consider how much additional code will be needed. We have to evaluate this for the FDW-based approach too, but it is likely to be smaller, which is its attraction. > because the architecture has already proven by the existence of > Postgres-XL itself. It's the prototype that proves the overall design, > even if the pieces change shape during the process. (Really, it's way > more than merely a prototype at this point because of how long it has > matured.) True, it is beyond a prototype. > In contrast, we don't have a prototype for FDW-based sharding; as you > admitted, there is no actual plan, other than "let's push FDWs in this > direction and hope that sharding will emerge". We don't really know > what pieces we need or how will they interact with each other; we have a > vague idea of a direction but there's no clear path forward. As the > saying goes, if you don't know where you're going, you will probably end > up somewhere else. I think I have covered that already. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
