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

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

From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
To: "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Hannu Krosing <hannu(at)tm(dot)ee>,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,"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 22:57:16
Message-ID: 20040930225716.GC7487@dcc.uchile.cl (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, Sep 30, 2004 at 04:57:37PM -0500, Jim C. Nasby wrote:

> Heh, I was about to ask for the pages with dead tuples list to be added
> to the TODO, but it seems it's already there ('Maintain a map of
> recently-expired rows'). One thing that isn't there which I remember
> being discussed was having the page-write daemon do a vacuum of a page
> before it's written; has this been done already?

Not done, but discussed.  One problem is that to vacuum a page, you may
need to bring the related index pages to memory, which is more work than
you are saving.

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,
because the index list isn't constructed until/unless someone explicitly
asks for it.  But anyway, do you have a lot of tables with no index?
And how many of them are big enough to warrant doing this?

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Having your biases confirmed independently is how scientific progress is
made, and hence made our great society what it is today" (Mary Gardiner)


In response to

Responses

pgsql-hackers by date

Next:From: Marc G. FournierDate: 2004-09-30 23:03:14
Subject: Re: CREATE INDEX speeds up query on 31 row table ...
Previous:From: Joe ConwayDate: 2004-09-30 22:56:02
Subject: Re: output branches before infinite recursion using connectby()?

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