On Thu, Apr 23, 2015 at 9:54 PM, Andres Freund <andres@anarazel.de> wrote: > > Split into a new thread, the other one is already growing fast > enough. This discussion started at > http://archives.postgresql.org/message-id/55391469.5010506%40iki.fi > > On April 23, 2015 6:48:57 PM GMT+03:00, Heikki Linnakangas <hlinnaka@iki.fi> wrote: > >Stop right there. You need to reserve enough space on the page to store > > > >an xmax for *every* tuple on the page. Because if you don't, what are > >you going to do when every tuple on the page is deleted by a different > >transaction. > > > >Even if you store the xmax somewhere else than the page header, you > >need > >to reserve the same amount of space for them, so it doesn't help at > >all. > > Depends on how you do it and what you optimize for (disk space, runtime, > code complexity..). You can e.g. use apply a somewhat similar trick to > xmin/xmax as done to cmin/cmax; only that the data structure needs to be > persistent.
Today while reading how other databases (that stores similar information
at page level) tackle this problem, I came across a link [1] which indicates
that this is controlled by some clauses (options) at table level. The idea
seems to be that have some preallocated space (minimum and maximum
value for which can be specified by user, ofcourse there will be some
default values for the same) for this information in page and if more space
than that is required for a concurrent write operation, then the operation
needs to wait till the space for the same is available.
I am not sure if this is the best way as it depends on how to re-use the
preallocated space for transaction information at page level, but still I