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.
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] |