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 <br...@momjian.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 + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
