From: | "Zeugswetter Andreas ADI SD" <ZeugswetterA(at)spardat(dot)at> |
---|---|
To: | "NikhilS" <nikkhils(at)gmail(dot)com>, "Gregory Stark" <stark(at)enterprisedb(dot)com> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Simon Riggs" <simon(at)2ndquadrant(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Frequent Update Project: Design Overview of HOT Updates |
Date: | 2006-11-10 14:34:25 |
Message-ID: | E1539E0ED7043848906A8FF995BDA579017C090A@m0143.s-mxs.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > I think the vision is that the overflow table would never be very
> > large because it can be vacuumed very aggressively. It has only
tuples
> > that are busy and will need vacuuming as soon as a transaction ends.
> > Unlike the main table which is mostly tuples that don't need
> > vacuuming.
Except when deleted :-)
> Thats right. vacuum if it gets a chance to work on the
> overflow relation seems to be doing a decent job in our runs.
> If autovacuum/vacuum gets to run optimally, the FSM
> information generated for the overflow relations will be able
> to serve a lot of new tuple requests avoiding undue/large
> bloat in the overflow relations.
It seems like we would want to create a chain into overflow for deleted
rows also (header + all cols null), so we can vacuum those too only by
looking
at overflow, at least optionally.
I think the overflow would really need to solve deletes too, or the
bitmap
idea is more generally useful to vacuum.
Generally for clear distinction I think we are talking about two things
here.
1. reduce index bloat and maintenance work
2. allow vaccuum a cheaper focus on what needs to be done
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Gevik Babakhani | 2006-11-10 15:16:46 | Protocol specs |
Previous Message | Pavan Deolasee | 2006-11-10 14:12:26 | Re: Frequent Update Project: Design Overview of HOTUpdates |