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.
>>> > > 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.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532) mobile: 512-569-9461
