From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Shridhar Daithankar <shridhar_daithankar(at)persistent(dot)co(dot)in> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Vacuum thoughts |
Date: | 2003-10-20 13:36:05 |
Message-ID: | 2125.1066656965@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Shridhar Daithankar <shridhar_daithankar(at)persistent(dot)co(dot)in> writes:
> I was thinking about it. How about vacuuming a page when it is been
> pushed out of postgresql buffer cache? It is is memory so not much IO
> is involved.
You keep ignoring the problem of removing index entries. To vacuum an
individual page, you need to be willing to read in (and update) all
index pages that reference the tuples-to-be-deleted. This is hardly
tenable when the reason for pushing the page out of buffer cache was so
that you could read in something else instead --- you don't have spare
buffer slots, and you don't want to do all that I/O (and the associated
WAL log entries) before you can read in the page you originally wanted.
The latter point is really the crux of the problem. The point of having
the VACUUM process is to keep maintenance work out of the critical path
of foreground queries. Anything that moves even part of that
maintenance work into the critical path is going to be a net loss.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jean-Michel POURE | 2003-10-20 13:55:54 | Re: [HACKERS] Mapping Oracle types to PostgreSQL types |
Previous Message | Eduardo D Piovesam | 2003-10-20 13:35:48 | Re: PostgreSQL on Novell Netware 6.5. |