Greg Stark <gsstark@mit.edu> writes:
> 2) Now that we don't have vacuum full the command-id is kind of a
> waste.
Not really.
> We could replace it with some kind of local memory data
> structure which is capable of spilling to disk.
The performance costs of that would probably outweigh any space savings.
> I think our phantom-command-id already has such issues anyways.
It can, but it's relatively uncommon to update a large number of tuples
more than once in a transaction. What you're suggesting would move that
bottleneck into mainstream cases. And it would be a bigger bottleneck
since you would have no lookup key available within the tuple header.
You'd have to use ctid as the lookup key which means no ability to use
one table entry for multiple rows, not to mention what do you do before
the tuple has a ctid assigned?
> 3) xmax and ctid are unavoidable since we never know when a tuple
> might be deleted or updated in the future. But if we allowed the user
> to mark a table "insert-only" then it could be left out and any
> operation which tries to delete, update, or select for update a row in
> the table would throw an error.
Anything with "this field is optional" is going to be a complete
disaster for mapping C structs over tuple headers...
regards, tom lane
