Tom Lane kirjoitti:
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.

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 Linnakangas

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to