Re: ARCHIVE TABLES (was: possible TODO: read-only tables, select from indexes only.)

From: "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>
To: Hannu Krosing <hannu(at)skype(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: ARCHIVE TABLES (was: possible TODO: read-only tables, select from indexes only.)
Date: 2005-05-02 20:59:36
Message-ID: 20050502205936.GX47820@decibel.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Out of curiosity, what would be required to allow deletes (but not
updates)? My thinking is that you'd want *some* way to be able to prune
data. Since you won't want to store an entire XID/CID for the delete, I
think it would be acceptable to keep a table of XID/CID values for
deletes and just store a pointer to that table in the tuple header. This
means you would be limited (perhaps severely) in the number of deletes
you could issue between vacuums, but for this instance that seems
perfectly reasonable. It might be worth using this same technique for
inserts as well. If the only inserting into the table is from some
nightly bulk process, you certainly don't need to store 4 (or is it 8)
bytes of inserting transaction data with each tuple.

Also, how does this allow for index scans without touching the heap?
AFAIK when a tuple is inserted but not committed it is already in the
index.
--
Jim C. Nasby, Database Consultant decibel(at)decibel(dot)org
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?"

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2005-05-02 21:00:36 Re: Feature freeze date for 8.1
Previous Message Rosser Schwarz 2005-05-02 20:58:16 Re: [HACKERS] Decision Process WAS: Increased company