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,
Pennsylvania19073