Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM) |
Дата | |
Msg-id | 20170224165816.GB23209@momjian.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM) (Pavan Deolasee <pavan.deolasee@gmail.com>) |
Список | pgsql-hackers |
On Fri, Feb 24, 2017 at 02:14:23PM +0530, Pavan Deolasee wrote: > > > On Thu, Feb 23, 2017 at 11:53 PM, Bruce Momjian <bruce@momjian.us> wrote: > > On Thu, Feb 23, 2017 at 03:03:39PM -0300, Alvaro Herrera wrote: > > Bruce Momjian wrote: > > > > > As I remember, WARM only allows > > > a single index-column change in the chain. Why are you seeing such a > > > large performance improvement? I would have thought it would be that > > > high if we allowed an unlimited number of index changes in the chain. > > > > The second update in a chain creates another non-warm-updated tuple, so > > the third update can be a warm update again, and so on. > > Right, before this patch they would be two independent HOT chains. It > still seems like an unexpectedly-high performance win. Are two > independent HOT chains that much more expensive than joining them via > WARM? > > > In these tests, there are zero HOT updates, since every update modifies some > index column. With WARM, we could reduce regular updates to half, even when we > allow only one WARM update per chain (chain really has a single tuple for this > discussion). IOW approximately half updates insert new index entry in *every* > index and half updates > insert new index entry *only* in affected index. That itself does a good bit > for performance. > > So to answer your question: yes, joining two HOT chains via WARM is much > cheaper because it results in creating new index entries just for affected > indexes. OK, all my questions have been answered, including the use of flag bits. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
В списке pgsql-hackers по дате отправления: