>When checking each tuple visibility, we always have to get the CSN >corresponding to XMIN or XMAX from CSN SLRU. In the past discussion, >there was the suggestion that CSN should be stored in the tuple header >or somewhere (like hint bit) to avoid the overhead by very frequehntly >lookup for CSN SLRU. I'm not sure the conclusion of this discussion. >But this patch doesn't seem to adopt that idea. So did you confirm that >such performance overhead by lookup for CSN SLRU is negligible? This patch came from postgrespro's patch which shows a good performance, I have simple test on current patch and result no performance decline. And not everytime we do a tuple visibility need lookup forCSN SLRU, only xid large than 'TransactionXmin' need that. Maybe we have not touch the case which cause bad performance, so it shows good performance temporary.
>Of course I know that idea has big issue, i.e., there is no enough space >to store CSN in a tuple header if CSN is 64 bits. If CSN is 32 bits, we may >be able to replace XMIN or XMAX with CSN corresponding to them. But >it means that we have to struggle with one more wraparound issue >(CSN wraparound issue). So it's not easy to adopt that idea... >Sorry if this was already discussed and concluded... I think your point with CSN in tuple header is a exciting approach, but I have not seen the discussion, can you show me the discussion address? Regards, Highgo Software (Canada/China/Pakistan) URL : www.highgo.ca EMAIL: mailto:movead(dot)li(at)highgo(dot)ca
