From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
Cc: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Heap WARM Tuples - Design Draft |
Date: | 2016-08-06 00:07:18 |
Message-ID: | 20160806000718.GB26927@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
From | Date | Subject | |
---|---|---|---|
Next Message | Shay Rojansky | 2016-08-06 00:07:37 | Re: Slowness of extended protocol |
Previous Message | Tom Lane | 2016-08-05 23:02:38 | Re: New version numbering practices |