On Mon, Sep 21, 2015 at 6:34 AM, Peter Geoghegan <p...@heroku.com> wrote: > > On Mon, Aug 31, 2015 at 9:49 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > > Increasing CLOG buffers to 64 helps in reducing the contention due to second > > reason. Experiments revealed that increasing CLOG buffers only helps > > once the contention around ProcArrayLock is reduced. > > There has been a lot of research on bitmap compression, more or less > for the benefit of bitmap index access methods. > > Simple techniques like run length encoding are effective for some > things. If the need to map the bitmap into memory to access the status > of transactions is a concern, there has been work done on that, too. > Byte-aligned bitmap compression is a technique that might offer a good > trade-off between compression clog, and decompression overhead -- I > think that there basically is no decompression overhead, because set > operations can be performed on the "compressed" representation > directly. There are other techniques, too. >
I could see benefits of doing compression for CLOG, but I think it won't be straight forward, other than handling of compression and decompression, currently code relies on transaction id to find the clog page, that will not work after compression or we need to do some changes in that mapping to make it work. Also I think it could avoid the increase of clog buffers which can help readers, but it won't help much for contention around clog updates for transaction status. Overall this idea sounds promising, but I think the work involved is more than the benefit I am expecting for the current optimization we are discussing. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
