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

Поиск
Список
Период
Сортировка
От Jim C. Nasby
Тема Re: ARCHIVE TABLES (was: possible TODO: read-only tables, select from indexes only.)
Дата
Msg-id 20050502205936.GX47820@decibel.org
обсуждение исходный текст
Ответ на ARCHIVE TABLES (was: possible TODO: read-only tables, select from indexes only.)  (Hannu Krosing <hannu@skype.net>)
Ответы Re: ARCHIVE TABLES (was: possible TODO: read-only tables, select from indexes only.)  (Jochem van Dieten <jochemd@gmail.com>)
Re: ARCHIVE TABLES (was: possible TODO: read-only  (Hannu Krosing <hannu@skype.net>)
Re: ARCHIVE TABLES (was: possible TODO: read-only  (Hannu Krosing <hannu@skype.net>)
Список 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@decibel.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?"


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Rosser Schwarz
Дата:
Сообщение: Re: [pgsql-advocacy] Decision Process WAS: Increased company
Следующее
От: Rosser Schwarz
Дата:
Сообщение: Re: [pgsql-advocacy] Decision Process WAS: Increased company