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.)
Re: ARCHIVE TABLES (was: possible TODO: read-only Re: ARCHIVE TABLES (was: possible TODO: read-only |
Список | 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 по дате отправления: