Re: Dead Space Map for vacuum - Mailing list pgsql-hackers

Simon Riggs wrote: <blockquote cite="mid1167417263.3903.245.camel@silverbirch.site" type="cite"><pre wrap="">On Fri,
2006-12-29at 10:49 -0500, Tom Lane wrote: </pre><blockquote type="cite"><pre wrap="">"Simon Riggs" <a
class="moz-txt-link-rfc2396E"href="mailto:simon@2ndquadrant.com"><simon@2ndquadrant.com></a> writes:
</pre><blockquotetype="cite"><pre wrap="">I would suggest that we tracked whether a block has had 0, 1 or 1+
 
updates/deletes against it. When a block has 1+ it can then be
worthwhile to VACUUM it and to place it onto the FSM. Two dead tuples is
really the minimum space worth reclaiming on any block.     </pre></blockquote><pre wrap="">How do you arrive at that
conclusion?  </pre></blockquote><pre wrap="">
 
FSM code ignores any block with less space than 1 average tuple, which
is a pretty reasonable rule. </pre></blockquote> FSM serves a different purpose than DSM and therefore has an entirely
differentset of rules governing what it should and shouldn't be doing.  This is a reasonable rule for FSM, but not for
DSM.<br/><blockquote cite="mid1167417263.3903.245.camel@silverbirch.site" type="cite"><pre wrap="">
 
If you only track whether a block has been updated, not whether it has
been updated twice, then you will be VACUUMing lots of blocks that have
only a 50% chance of being usefully stored by the FSM. As I explained,
the extra bit per block is easily regained from storing less FSM data. </pre></blockquote> Well, it seems that when
implementingthe DSM, it'd be a great time to move FSM from it's current location in Shared Memory to somewhere else. 
Possiblythe same place as DSM.  A couple of special blocks per file segment would a good place.  Also I'm not sure that
thepoint of VACUUMing is always to be able be able to immediately reuse the space.  There are cases where large
DELETE'sare done, and you just want to decrease the index size.  In Tom's counter example of large tuples, you
certainlywant to vacuum the index when only a single update/delete occurs.<br /><blockquote
cite="mid1167417263.3903.245.camel@silverbirch.site"type="cite"><pre wrap="">
 
My understanding was that DSM was meant to increase VACUUM efficiency,
so having a way to focus in on blocks most worth vacuuming makes sense
using the 80/20 rule. </pre></blockquote> Possibly true.  I don't have anything to indicate what usage patterns produce
whatrequirements in vacuum patterns.  If there are significant numbers of blocks with one update, is it a loss to
actuallyvacuum those.  I know it could be faster if we didn't, but would it still be faster than what we do now.<br
/><blockquotecite="mid1167417263.3903.245.camel@silverbirch.site" type="cite"><pre wrap=""> </pre><blockquote
type="cite"><prewrap="">Counterexample: table in which all tuples exceed half a page.   </pre></blockquote><pre
wrap="">
Current FSM code will ignore those too, if they are less than the
average size of the tuple so far requested. Thats a pretty wierd
counterexample, even if it is a case that needs handling. </pre></blockquote> Again I'd be careful saying that FSM =
DSMfor handling of what should be done for a particular block.<br /><br /> Russell Smith.<br /><br />