Re: Some ideas about Vacuum - Mailing list pgsql-hackers

From Gokulakannan Somasundaram
Subject Re: Some ideas about Vacuum
Date
Msg-id 9362e74e0801160034w2524c0bs74754365cab5d9f@mail.gmail.com
Whole thread Raw
In response to Re: Some ideas about Vacuum  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Some ideas about Vacuum  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
List pgsql-hackers
<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt
0pt0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br /></div>Well, one of the principal arguments for having
VACUUMat all is that it <br />off-loads required maintenance effort from foreground transaction code<br />paths.  I'm
notreally going to be in favor of solutions that put more<br />work into the transaction code paths (HOT already did
moreof that than <br />I would like :-().  OTOH, I agree that scanning the WAL log doesn't<br />really sound like
somethingwell-matched to this problem either.<br /></blockquote></div><br />Tom, Don't you like the idea of building
somemore structures around WAL, like Asynchronous Materialized views. Indexes, if implemented as  stated, would remove
theHOT code in the path of the transaction(as you may know).  I am also slightly doubtful of the argument, that doing
full-tablescans and full index scans for Vacuum is efficient. Can you please advise me on why we should not use a read
onlyoperation on WAL log ? <br /><br />Thanks,<br />Gokul.<br /> 

pgsql-hackers by date:

Previous
From: "Gokulakannan Somasundaram"
Date:
Subject: Re: Some ideas about Vacuum
Next
From: "Gokulakannan Somasundaram"
Date:
Subject: Re: WAL logging of hash indexes