Re: [WIP] Effective storage of duplicates in B-tree index.
От | Peter Geoghegan |
---|---|
Тема | Re: [WIP] Effective storage of duplicates in B-tree index. |
Дата | |
Msg-id | CAM3SWZQ4Auura0P-wyLEPmvB-caw9NBhA_Hyz=1oOiG1CjhjWw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [WIP] Effective storage of duplicates in B-tree index. (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [WIP] Effective storage of duplicates in B-tree index.
(Anastasia Lubennikova <a.lubennikova@postgrespro.ru>)
Re: [WIP] Effective storage of duplicates in B-tree index. (Claudio Freire <klaussfreire@gmail.com>) |
Список | pgsql-hackers |
On Thu, Mar 24, 2016 at 7:17 AM, Robert Haas <robertmhaas@gmail.com> wrote: > I really like this idea, and the performance results seem impressive, > but I think we should push this out to 9.7. A btree patch that didn't > have WAL support until two and a half weeks into the final CommitFest > just doesn't seem to me like a good candidate. First, as a general > matter, if a patch isn't code-complete at the start of a CommitFest, > it's reasonable to say that it should be reviewed but not necessarily > committed in that CommitFest. This patch has had some review, but I'm > not sure how deep that review is, and I think it's had no code review > at all of the WAL logging changes, which were submitted only a week > ago, well after the CF deadline. Second, the btree AM is a > particularly poor place to introduce possibly destabilizing changes. > Everybody depends on it, all the time, for everything. And despite > new tools like amcheck, it's not a particularly easy thing to debug. Regrettably, I must agree. I don't see a plausible path to commit for this patch in the ongoing CF. I think that Anastasia did an excellent job here, and I wish I could have been of greater help sooner. Nevertheless, it would be unwise to commit this given the maturity of the code. There have been very few instances of performance improvements to the B-Tree code for as long as I've been interested, because it's so hard, and the standard is so high. The only example I can think of from the last few years is Kevin's commit 2ed5b87f96 and Tom's commit 1a77f8b63d both of which were far less invasive, and Simon's commit c7111d11b1, which we just outright reverted from 9.5 due to subtle bugs (and even that was significantly less invasive than this patch). Improving nbtree is something that requires several rounds of expert review, and that's something that's in short supply for the B-Tree code in particular. I think that a new testing strategy is needed to make this easier, and I hope to get that going with amcheck. I need help with formalizing a "testing first" approach for improving the B-Tree code, because I think it's the only way that we can move forward with projects like this. It's *incredibly* hard to push forward patches like this given our current, limited testing strategy. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: