Re: Reviving Time Travel (was Re: 'TID index')

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
Cc: "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Hannu Krosing <hannu(at)tm(dot)ee>, "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Reviving Time Travel (was Re: 'TID index')
Date: 2004-09-30 23:11:29
Message-ID: 1410.1096585889@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> One idea would be to vacuum the page if it can be determined that the
> relation doesn't have indexes. This information is generally not known,

... especially not by the page writer. You can't assume that you have
access to the relation descriptor --- for instance, it's entirely
possible that the bgwriter (or another backend) will need to push out a
dirty page that belongs to a newly created relation for which the
catalog data remains uncommitted. There are related scenarios involving
uncommitted drops.

More generally I think that invoking VACUUM processing from the bgwriter
would be a serious violation of the module hierarchy, and would inflict
more pain in the form of bugs and maintenance headaches than it could
possibly be worth. We just this version managed to get smgr decoupled
from the relcache, like it should have been all along. (bufmgr should
be too, but I haven't tackled that yet...) This was actually a
necessary step to make the separate bgwriter feasible. Let's not
reverse that cleanup in pursuit of dubious optimizations.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bernd Helmle 2004-09-30 23:21:00 Bug in CREATE VIEW grammar
Previous Message Marc G. Fournier 2004-09-30 23:04:30 Re: CREATE INDEX speeds up query on 31 row table ...