<div dir="ltr"><div class="gmail_extra">On Wed, Nov 13, 2013 at 9:24 AM, Jens W. Klein <span dir="ltr"><<a href="mailto:jens@bluedynamics.com" target="_blank">jens@bluedynamics.com</a>></span> wrote:<br><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":1ab" style="overflow:hidden">Thanks Martijn for the hint, but we are using a history free database, so growing does only happen by deleted objects in our case.<br>

</div></blockquote><div><br></div><div>Right, that is an important distinction.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":1ab" style="overflow:hidden">


When in history free mode, is it possible to detect deleted objects at store-time? This way we could add the zoid at store time to a objects_deleted table in order to clean them up later.<br></div></blockquote><div><br></div>

<div>No, because multiple references to an object might exist. There is no reference counting in a ZODB, hence the intensive manual tree traversal job when garbage collecting.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div id=":1ab" style="overflow:hidden">
Another way to speed up graph traversal would be to store the object-references in a field of object_state. At the moment we have to read the pickle in order to get the referenced zoids. Storing additional - redundant - information might be not perfect, but it would allow to pack/gc the database without any knowledge about the state objects structure, i.e. using a stored procedure.<br>

</div></blockquote><div><br></div><div>That sounds like a feasible idea, at least to me.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":1ab" style="overflow:hidden">


I would like to know what the relstorage experts think about this ideas.<br></div></blockquote></div><br>You may want to contact Shane directly, he *may* not be reading this list actively.<br><br>-- <br>Martijn Pieters<br>


</div></div>