Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group