Gregory Stark <[EMAIL PROTECTED]> 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.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
