Re: Corrupted btree index on HEAD because of covering indexes - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Corrupted btree index on HEAD because of covering indexes
Date
Msg-id CAH2-WzkUoU=1++PPdh-ym+Hmyhopwo+H2Rvzegf78_ttgDZDwA@mail.gmail.com
Whole thread Raw
In response to Re: Corrupted btree index on HEAD because of covering indexes  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
List pgsql-hackers
On Wed, Apr 25, 2018 at 2:09 PM, Alexander Korotkov
<a.korotkov@postgrespro.ru> wrote:
> Great.  Thank you very much for your efforts on this feature!

You're welcome. I also appreciate the efforts of all Postgres Pro
people. I especially appreciate Anastasia's work on this project.

I hope that we see more B-Tree patches from Anastasia, and others.
Getting this patch over the line was, it must be said, pretty painful
for everyone. There were many reasons for that, some good, others not
so good. However, I think that we've learned a few things about how to
manage the risks around a patch like this one. This will hopefully
make it significantly easier to do more work in this area. I think
that it's badly needed. I think that its importance is generally
underestimated, actually. The Gray and Reuter book says "B-Trees are
by far the most important access path structure in database and file
systems". I believe that that's just as true now, 25 years later.

The core algorithms that are used by nbtree are generally very well
implemented, and I don't think it's a good idea to work on features
that change that. At least, I won't be working on something like
merging of non-empty pages myself (or anything that touches
concurrency, page deletion, etc). However, I do think that we can
significantly improve nbtree for certain workloads by optimizing the
representation at the page level, which I'm glad to see more interest
in in the past few years. The major difficulty here is choosing an
on-disk representation that lets us do everything that we'll want to
do in the future. That requires strong cooperation.

-- 
Peter Geoghegan


pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: Re: WIP: a way forward on bootstrap data
Next
From: Peter Geoghegan
Date:
Subject: Re: [HACKERS] Clock with Adaptive Replacement