Manfred Koizar wrote: > On Fri, 2 Sep 2005 20:41:48 -0400 (EDT), Bruce Momjian > <pgman@candle.pha.pa.us> wrote: > >> Once I had a patch based on 7.4 that stored cmin and cmax in > >> backend-local memory. > > >Interesting idea, but how would you record the cmin/xmin values without > >requiring unlimited memory? > > That's exactly the reason for not sending it to -patches. Without > spilling to disk this is just not ready for real life. The problem is > that -- unlike other data structures that build up during a > transaction, e.g. trigger queues -- cmin/cmax lookup requires random > access, so we'd need some form of tree or hash. Unfornunately I never > got beyond brainstorming :-(
What we do for shared row locks is much more compact because we create a phantom xid for combination of xids and store that in a hash. I think the problem with having cmin/cmax in local memory is that without a way to stamp a row with some fake cid (as is suggested in the TODO item now) there is really no way to _group_ rows together to store their values as a single item in local memory, meaning we would have to store ctids or something for each row, and that seems unscalable. I have added your memory-only idea to the TODO item because it highlights that cmin/cmax is never looked at outside the backend that is modifying the row. If there was a tuple header field we can use just while the row is being created or expired we could use that, but I don't see one. Could we recalculated one of the fields after it is created/expired? I don't know. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
