From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
Cc: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, Claudio Freire <klaussfreire(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Heap WARM Tuples - Design Draft |
Date: | 2016-08-10 02:07:41 |
Message-ID: | 20160810020741.GA21285@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Aug 9, 2016 at 06:19:57PM -0500, Jim Nasby wrote:
> On 8/8/16 3:19 PM, Bruce Momjian wrote:
> >>What will help, and something I haven't yet applied any thoughts, is when we
> >>> can turn WARM chains back to HOT by removing stale index entries.
> >I can't see how we can ever do that because we have multiple indexes
> >pointing to the chain, and keys that might be duplicated if we switched
> >to HOT. Seems only VACUUM can fix that.
>
> Are these changes still predicated on being able to re-find all index
> entries by key value? If so, that makes incremental vacuums practical,
> perhaps eliminating a lot of these issues.
No, the increment/decrement doesn't require btree lookups.
> >>>> > We can't use the bits LP_REDIRECT lp_len because we need to create WARM
> >>>> > chains before pruning, and I don't think walking the pre-pruned chain is
> >>>> > worth it. (As I understand HOT, LP_REDIRECT is only created during
> >>>> > pruning.)
> >>>
> >>> That's correct. But lp_len provides us some place to stash information from
> >>> heap tuples when they are pruned.
> >Right. However, I see storing information at prune time as only useful
> >if you are willing to scan the chain, and frankly, I have given up on
> >chain scanning (with column comparisons) as being too expensive for
> >its limited value.
>
> What if some of this work happened asynchronously? I'm thinking something
> that runs through shared_buffers in front of bgwriter.
Well, we prune when we need the space --- that is the big value of page
pruning, that it is fast can be done when you need it. VACUUM is all
about background cleanup.
--
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 | Kyotaro HORIGUCHI | 2016-08-10 02:08:43 | Re: handling unconvertible error messages |
Previous Message | Jim Nasby | 2016-08-10 00:17:14 | Re: Notice lock waits |