Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)
От | Alvaro Herrera |
---|---|
Тема | Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM) |
Дата | |
Msg-id | 20170201003653.nxrlbmlhzhmq4zzc@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)
Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM) |
Список | pgsql-hackers |
Tom Lane wrote: > BTW, the reason I think it's good cleanup is that it's something that my > colleagues at Salesforce also had to do as part of putting PG on top of a > different storage engine that had different ideas about index handling. > Essentially it's providing a bit of abstraction as to whether catalog > storage is exactly heaps or not (a topic I've noticed Robert is starting > to take some interest in, as well). Yeah, I remembered that too. Of course, we'd need to change the whole idea of mapping tuples to C structs too, but this seemed a nice step forward. (I renamed Pavan's proposed routine precisely to avoid the word "Heap" in it.) > However, the patch misses an > important part of such an abstraction layer by not also converting > catalog-related simple_heap_delete() calls into some sort of > CatalogTupleDelete() operation. It is certainly a peculiarity of > PG heaps that deletions don't require any immediate index work --- most > other storage engines would need that. > I propose that we should finish the job by inventing CatalogTupleDelete(), > which for the moment would be a trivial wrapper around > simple_heap_delete(), maybe just a macro for it. > > If there's no objections I'll go make that happen in a day or two. Sounds good. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: