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
EnterpriseDB http://www.enterprisedb.com
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
