Re: Reduction in WAL for UPDATEs
От | Simon Riggs |
---|---|
Тема | Re: Reduction in WAL for UPDATEs |
Дата | |
Msg-id | 1175065634.4386.267.camel@silverbirch.site обсуждение исходный текст |
Ответ на | Re: Reduction in WAL for UPDATEs (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Reduction in WAL for UPDATEs
Re: Reduction in WAL for UPDATEs |
Список | pgsql-hackers |
On Tue, 2007-03-27 at 20:48 -0400, Tom Lane wrote: > "Simon Riggs" <simon@2ndquadrant.com> writes: > > It seems possible to reduce overall WAL volume by roughly 25% on common > > workloads by optimising the way UPDATE statements generate WAL. > > This seems a huge amount of work to optimize *one* benchmark. Please don't beat me with that. I wouldn't suggest it if I didn't think it would help real users. The analysis of the WAL volume was done using a benchmark, but only as a guide to indicate likely usage patterns. There aren't many real world heavy UPDATE scenarios to analyze right now because people have previously actively avoided such usage. > If it > weren't so narrowly focused on the properties of a particular benchmark > (mostly UPDATE, mostly a few columns in wide tuples), I'd get more > excited. Updating the current balance on a Customer Account is one of the main focus areas for HOT. Those records are typically at least 250 bytes long, so we can save ~200 bytes of WAL per UPDATE for the most frequent types of UPDATE. Sure, not all UPDATEs would be optimised, but then they are much less frequent. As I mentioned, the WAL volume is disproportionately generated by UPDATEs of longer rows, so optimising WAL for just a few tables can make a big difference to the overall volume. > The extra time spent holding exclusive lock on the page > doesn't sound attractive either ... Agreed, thats why I set a fairly high bar for when this would kick in. The fewer rows on a page, the less contention. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: