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
