Re: Performance Improvement by reducing WAL for Update Operation
От | Robert Haas |
---|---|
Тема | Re: Performance Improvement by reducing WAL for Update Operation |
Дата | |
Msg-id | CA+TgmoZcLqZwToELm0t7JLNZH6jEKeqMGE3cctmpCh6tpKqP3Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Performance Improvement by reducing WAL for Update Operation (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Performance Improvement by reducing WAL for Update
Operation
Re: Performance Improvement by reducing WAL for Update Operation |
Список | pgsql-hackers |
On Wed, Nov 27, 2013 at 9:31 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: > Sure, but to explore (a), the scope is bit bigger. We have below > options to explore (a): > 1. try to optimize existing algorithm as used in patch, which we have > tried but ofcourse we can spend some more time to see if anything more > can be tried out. > 2. try fingerprint technique as suggested by you above. > 3. try some other standard methods like vcdiff, lz4 etc. Well, obviously, I'm hot on idea #2 and think that would be worth spending some time on. If we can optimize the algorithm used in the patch some more (option #1), that would be fine, too, but the code looks pretty tight to me, so I'm not sure how successful that's likely to be. But if you have an idea, sure. As to #3, I took a look at lz4 and snappy but neither seems to have an API for delta compression. vcdiff is a commonly-used output for delta compression but doesn't directly address the question of what algorithm to use to find matches between the old and new input; and I suspect that when you go searching for algorithms to do that efficiently, it's going to bring you right back to #2. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: