Re: Making all nbtree entries unique by having heap TIDs participatein comparisons - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Making all nbtree entries unique by having heap TIDs participatein comparisons
Date
Msg-id 75723f17-dedd-d73f-cdca-61c95ee71293@iki.fi
Whole thread Raw
In response to Re: Making all nbtree entries unique by having heap TIDs participate in comparisons  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: Making all nbtree entries unique by having heap TIDs participatein comparisons
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: current_logfiles not following group access and instead followslog_file_mode permissions
Next
From: Andy Fan
Date:
Subject: Re: Suggestions on message transfer among backends