Tom Lane wrote:<br /><blockquote cite="mid5876.1039765041@sss.pgh.pa.us" type="cite"><pre wrap="">Janardhan <a
class="moz-txt-link-rfc2396E"href="mailto:jana-reddy@mediaring.com.sg"><jana-reddy@mediaring.com.sg></a> writes:
</pre><blockquotetype="cite"><pre wrap="">Does it breaks any other things if all the index entries pointing the
dead tuple are removed before reusing the dead tuple?. </pre></blockquote><pre wrap="">
Possibly you could make that work, but I think you'll find the
efficiency advantage you were chasing to be totally gone. The locking
scheme is heavily biased against you, and the index AMs don't offer an
API designed for efficient retail index-tuple deletion.
Of course that just says that you're swimming against the tide of
previous optimization efforts. But the thing you need to face up to
is you are taking what had been background maintenance tasks (viz,
VACUUM) and moving them into the foreground critical path. This *will*
slow down your foreground applications.
regards, tom lane
</pre></blockquote> today i could able to complete the patch and it is working only for b-tree. i have added a new
methodam_delete <br /> to the API and bt_delete to the B-tree index to delete a single entry. for the timebeing
thisworks only with<br /> b-tree indexs.<br /><br /> Regarding the complexity of deleting a tuple from b-tree , it is
sameor less then that of<br /> inserting a tuple into a B-tree( since delete does not require spliting the page). The
approachis slightly <br /> different to that of lazy vacuum. lazy vacuum scan entire index table to delete the dead
entries.<br/> here it search for the pariticilar entry similer to that of insert . <br /> here locking may not have
muchimpact. It locks only single buffer to delete the index entry.<br /><br /> Regarding the efficiency, if the
entireIndex table is in buffered then it does not require any <br /> additional IO , only extra CPU is required to
deleteentries in index table.<br /> I am using postgres in a application where is there is heavy updates for group of
tables(smallsize), before inserting<br /> a single record in huge table. this entire thing constitue single
transaction.currently as time goes on the transaction <br /> processing speed decreases till the database is vacuumed.
<br/><br /> Using this new patch i am hoping the trasaction processing time will remain constant irrespective of time.
Onlyi need to do<br /> vaccum once i delete large number of entries from some of the tables.<br /><br /> regards,
jana<br/><br />