Re: InnoDB compression - in-page modification log
Posted by:
osi shkin
Date: September 16, 2014 03:13AM
Thanks for the replies guys. I thought as much. It does seems like a potential source of inefficienecy, since this can easily result in read-mofify-write behavior for the entire compressed page when dumping it with the modification log.
Adding compression on an existing system usually results in these types of problems, so no finger pointing on my part, just wanted to verify that I got it right.
I'm not sure if FALLOC_FL_PUNCH_HOLE is the answer (if I understand it correctly from the man page). Maybe partially. Say you have data that is say 50% compressible (which is common in databases), using 16K MySQL pages and 8K compressed page size.
In this case you'll get a lot of data that compresses to a little above, and a little below 8K. Bottom line you're still stuck with tails of 4K blocks that are not used (assuming 4K blocks are used, which I think is typical today) and dumping a lot of zero data to the disk, ending up with the same read-modify-write behavior. the Modification log at least attempts to utilize these zero ends.
Subject
Views
Written By
Posted
1690
September 06, 2014 02:42AM
812
September 07, 2014 12:11PM
1002
September 10, 2014 07:38AM
Re: InnoDB compression - in-page modification log
1007
September 16, 2014 03:13AM
Sorry, you can't reply to this topic. It has been closed.
Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion
of Oracle or any other party.