Re: Making all nbtree entries unique by having heap TIDs participatein comparisons

On 12/03/2019 04:47, Peter Geoghegan wrote:
> In conclusion: I think that this regression is a cost worth accepting.
> The regression in throughput is relatively small (2% - 3%), and the
> NEW_ORDER transaction seems to be the only problem (NEW_ORDER happens
> to be used for 45% of all transactions with TPC-C, and inserts into
> the largest index by far, without reading much). The patch overtakes
> master after a few hours anyway -- the patch will still win after
> about 6 hours, once the database gets big enough, despite all the
> contention. As I said, I think that we see a regression*because*  the
> indexes are much smaller, not in spite of the fact that they're
> smaller. The TPC-C/BenchmarkSQL indexes never fail to be about 40%
> smaller than they are on master, no matter the details, even after
> many hours.

Yeah, that's fine. I'm curious, though, could you bloat the indexes back 
to the old size by setting the fillfactor?

- Heikki