On Fri, Aug 5, 2016 at 9:21 PM, Claudio Freire <klaussfre...@gmail.com> wrote: > On Fri, Aug 5, 2016 at 9:07 PM, Bruce Momjian <br...@momjian.us> wrote: >> On Fri, Aug 5, 2016 at 07:51:05PM -0300, Claudio Freire wrote: >>> > This does create more HOT chains where the root ctid cannot be removed, >>> > but it does avoid the index key/ctid check because any entry in the HOT >>> > chain has identical keys. What this would not handle is when an entire >>> > HOT chain is pruned, as the keys would be gone. >>> >>> I believe the only solution is to use bitmap index scans with WARM indexes. >> >> Let me back up and explain the benefits we get from allowing HOT chains >> to be WARM: >> >> * no index entries for WARM indexes whose values don't change >> * improved pruning because the HOT/WARM chains can be longer because we >> don't have to break chains for index changes >> >> While I realize bitmap indexes would allow us to remove duplicate index >> entries, it removes one of the two benefits of WARM, and it causes every >> index read to be expensive --- I can't see how this would be a win over >> doing the index check on writes. > > But the index check could be prohibitely expensive.
Well... it could be made efficient for the case of nbtree with a format change. If nbtree sorted by tid as well, for instance. But an upgrade there would involve a reindex before WARM can be applied. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
