Hi, Gokulakannan Somasundaram wrote:
I'm also not sure it really buys us anything over having a second dead-space-map data structure. The WAL is much larger and serves other purposes which would limit what we can do with it.Ok. One obvious advantage is that it saves the contention over DSM for the DML operations and Vacuum process.
Do you have evidence of that contention being so worse, that it justifies the additional WAL reading from disk? (Assuming no WAL archiving).
IMO we can get about any granularity we want for DSM update locking, depending on how we arrange the DSM bits.
Since Vacuum process is going to have much more information on what has happened in the database,
Why should that be? IMO, collecting the information at transaction time can give you exactly the same information, if not more or better information.
it is possible for some new structures. For example i have been thinking of changing our current index structure in such a way, it won't hold any duplicate tuples for different versions of data. Whenever there is a update, only the indexes relevant to the columns changed will get updated. The Vacuum has to play the role of changing the tid, the index tuple points to, whenever it vacuums a older version.
Huh? The index would then point to the old tuple only, until a VACUUM comes by, right. How are following transactions expected to find the new tuple before that VACUUMing?
Regards Markus ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
