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