If you're going to do this I would suggest keeping in mind that a similar tactic could be used to help keep a table clustered (I think there may even be a TODO on that). The basic idea there is to use the clustering index to decide the best page to put a tuple on and try and return that page (or one close to it) from the FSM.
On Tue, Jul 12, 2005 at 04:30:04PM +0300, Hannu Krosing wrote: > > Where in the source is the decision about the placement new tuple (on > which page to put it) made ? > > I'd like to take a look at adding "gravity" to that decision, do that I > can make postgres to decide to place new tuple (inserted or updated) > near the beginning of file, in order to make it possible for ordinary > (lazy) vacuum to shrink relations more often, initially controlled by > GUC, maybe later by some other, more automatic hints, like % of empty > pages. > > My current jedi mindtricks (seqscan + update pk=pk on last tuple until > its page nr in ctid changes) for shrinking relations do work, but not as > well as I'd like them to ;) > > -- > Hannu Krosing <[EMAIL PROTECTED]> > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend > -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?" ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster