On Tue, Mar 14, 2017 at 8:14 PM, Peter Geoghegan <pg@bowt.ie> wrote:
On Tue, Mar 14, 2017 at 12:19 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > Impressive results.
Agreed.
Thanks. I repeated the same tests with slightly lower scale factor so that most (but not all) data fits in memory. The results are kinda similar (attached here). The spikes are still there and they correspond to the checkpoint_timeout set for these tests.
It seems like an important invariant for WARM is that any duplicate index values ought to have different TIDs (actually, it's a bit stricter than that, since btrecheck() cares about simple binary equality).
Yes. I think in the current code, indexes can never duplicate TIDs (at least for btrees and hash). With WARM, indexes can have duplicate TIDs, but iff index values differ. In addition there can only be one more duplicate and one of them must be a Blue pointer (or a non-WARM pointer if we accept the new nomenclature proposed a few mins back).
You wouldn't have to teach amcheck about the heap, because a TID that points to the heap can only be duplicated within a B-Tree index because of WARM. So, if we find that two adjacent tuples are equal, check if the TIDs are equal. If they are also equal, check for strict binary equality. If strict binary equality is indicated, throw an error due to invariant failing.
Wouldn't this be much more expensive for non-unique indexes?
