Re: Getting rid of cmin and cmax

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org, mkoi-pg(at)aon(dot)at
Subject: Re: Getting rid of cmin and cmax
Date: 2006-09-19 17:05:38
Message-ID: 7822.1158685538@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Gregory Stark <stark(at)enterprisedb(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Martijn van Oosterhout 2006-09-19 17:05:43 Re: [pgsql-www] Developer's Wiki
Previous Message Gregory Stark 2006-09-19 17:00:21 Re: Getting rid of cmin and cmax