Re: Getting rid of cmin and cmax - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Getting rid of cmin and cmax
Date
Msg-id 7822.1158685538@sss.pgh.pa.us
Whole thread Raw
In response to Re: Getting rid of cmin and cmax  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: Getting rid of cmin and cmax
Next
From: Martijn van Oosterhout
Date:
Subject: Re: [pgsql-www] Developer's Wiki