Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

Поиск
Список
Период
Сортировка
От Pavan Deolasee
Тема Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)
Дата
Msg-id CABOikdMzPC2=0G0wZv8P=zQzHW7z6Xm+jsKc_-bAuqrvXjbiLw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)  (Pavan Deolasee <pavan.deolasee@gmail.com>)
Ответы Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers

On Tue, Jan 3, 2017 at 9:43 AM, Pavan Deolasee <pavan.deolasee@gmail.com> wrote:
The patch still disables WARM on system tables, something I would like to fix. But I've been delaying that because it will require changes at several places since indexes on system tables are managed separately.

Here is another version which fixes a bug that I discovered while adding support for system tables. The patch set now also includes a patch to enable WARM on system tables. I'm attaching that as a separate patch because while the changes to support WARM on system tables are many, almost all of them are purely mechanical. We need to pass additional information to CatalogUpdateIndexes()/CatalogIndexInsert(). We need to tell these routines whether the update leading to them was a WARM update and which columns were modified so that it can correctly avoid adding new index tuples for indexes for which index keys haven't changed.

I wish I could find another way of passing this information instead of making changes at so many places, but the only other way I could think of was tracking that information as part of the HeapTuple itself, which doesn't seem nice and may also require changes at many call sites where tuples are constructed. One minor improvement could be that instead of two, we could just pass "modified_attrs" and a NULL value may imply non-WARM update. Other suggestions are welcome though.

I'm quite happy that all tests pass even after adding support for system tables. One reason for testing support for system tables was to ensure some more code paths get exercised. As before, I've included Alvaro's refactoring patch too.

Thanks,
Pavan

--
 Pavan Deolasee                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: [HACKERS] merging some features from plpgsql2 project
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: [HACKERS] [COMMITTERS] pgsql: Update copyright for 2017