Re: Getting rid of cmin and cmax

Tom Lane kirjoitti:
> Gregory Stark <stark@enterprisedb.com> writes:
>> Frankly the whole phantom commandid thing sounds more complicated. 
>> You *still*
>> need a local state data structure that *still* has to spill to disk 
>> and now
>> it's much harder to characterize how large it will grow since it 
>> depends on
>> arbitrary combinations of cmin and cmax.
>
> Yeah, but it requires only one entry when a command processes
> arbitrarily large numbers of tuples, so in practice it's not going to
> need to spill to disk. What Heikki wants to do will require an entry in
> local memory for *each tuple* modified by a transaction. That will ruin
> performance on a regular basis.

As I tried to say in the first post, I believe we can actually get away 
without an entry in local memory in typical scenarios, including bulk 
data loads. Bulk updates are probably the biggest problem, but I think 
we could handle even them just fine with the right data structure.

-- Heikki LinnakangasEnterpriseDB   http://www.enterprisedb.com