Robert Haas wrote: > 2. The other fairly obvious alternative is to adjust our existing WAL > record types to be idempotent - i.e. to not rely on the existing page > contents. For XLOG_HEAP_INSERT, we currently store the target tid and > the tuple contents. I'm not sure if there's anything else, but we > would obviously need the offset where the new tuple should be written, > which we currently infer from reading the existing page contents. For > XLOG_HEAP_DELETE, we store just the TID of the target tuple; we would > certainly need to store its offset within the block, and maybe the > infomask. For XLOG_HEAP_UPDATE, we'd need the old and new offsets and > perhaps also the old and new infomasks. Assuming that's all we need > and I'm not missing anything (which I won't bet on), that means we'd > be adding, say, 4 bytes per insert or delete and 8 bytes per update. > So, if checkpoints are spread out widely enough that there will be > more than ~2K operations per page between checkpoints, then it makes > more sense to just do a full page write and call it good. If not, > this idea might have legs.
I vote for "wal_level = idempotent" because so few people will know what idempotent means. ;-) Idempotent does seem like the most promising idea. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
