Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)
От | Andres Freund |
---|---|
Тема | Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM) |
Дата | |
Msg-id | 20170131215538.5c65rexachourokl@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM) (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)
Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM) |
Список | pgsql-hackers |
On 2017-01-31 14:10:01 -0300, Alvaro Herrera wrote: > Pavan Deolasee wrote: > > > Two new APIs added. > > > > - CatalogInsertHeapAndIndex which does a simple_heap_insert followed by > > catalog updates > > - CatalogUpdateHeapAndIndex which does a simple_heap_update followed by > > catalog updates > > > > There are only a handful callers remain for simple_heap_insert/update after > > this patch. They are typically working with already opened indexes and > > hence I left them unchanged. > > Hmm, I was thinking we would get rid of CatalogUpdateIndexes altogether. > Two of the callers are in the new routines (which I propose to rename to > CatalogTupleInsert and CatalogTupleUpdate); the only remaining one is in > InsertPgAttributeTuple. I propose that we inline the three lines into > all those places and just remove CatalogUpdateIndexes. Half the out-of- > core places that are using this function will be broken as soon as WARM > lands anyway. I see no reason to keep it. (I have already modified the > patch this way -- no need to resend). > > Unless there are objections I will push this later this afternoon. Hm, sorry for missing this earlier. I think CatalogUpdateIndexes() is fairly widely used in extensions - it seems like a pretty harsh change to not leave some backward compatibility layer in place. Andres
В списке pgsql-hackers по дате отправления: