Gregory Stark <stark@enterprisedb.com> writes:
> Well there's a reason we support commandids up to 4 billion. One of the common
> use cases of bulk loading data in a series of individual inserts would cause
> such a structure to spill to disk. As would ISAM style programming that steps
> through a large data set and updates rows one by one.
You're missing the point though, which is that no memory entry is needed
at all unless the same tuple has been both inserted and deleted in the
current transaction. Bulk data loads will incur zero entries in this
scheme, whereas what Heikki has in mind will incur an entry per tuple.
regards, tom lane