Re: autovacuum next steps, take 2

From: Galy Lee <lee(dot)galy(at)oss(dot)ntt(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>, "Jim C(dot) Nasby" <jim(at)nasby(dot)net>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Hackers <pgsql-hackers(at)postgresql(dot)org>, Gregory Stark <stark(at)enterprisedb(dot)com>
Subject: Re: autovacuum next steps, take 2
Date: 2007-02-28 01:51:58
Message-ID: 45E4E03E.1090002@oss.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Tom Lane wrote:
> Saving the array is
> expensive both in runtime and code complexity, and I don't believe we
> can trust it later --- at least not without even more expensive-and-
> complex measures, such as WAL-logging every such save :-(
I don’t understand well the things you are worrying about.
If we find that we can not trust the saved file, or the file has
corrupted, then we can drop it and scan from the beginning of the heap
block. If something like CLUSTER, PITR has changed the physical layout
of heap, then we can simply drop the files. Why do we need WAL for it?
I don’t see any point in it.

Also, I don’t think it is expensive. If it is combined with maintenance
window to stop once in a whole day, writing 256MB/2 = 128MB things out
can not be said expensive. Of course, this feature isn’t for autovacuum
to use it in every minutes, autovacuum can use it after it has adopted
maintenance window.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2007-02-28 01:57:16 Re: COMMIT NOWAIT Performance Option
Previous Message Neil Conway 2007-02-28 01:51:19 Re: [HACKERS]