Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)
От | Anastasia Lubennikova |
---|---|
Тема | Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables) |
Дата | |
Msg-id | 44fd10a5-2d16-86a4-5192-b85a6a16790c@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables) (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
05.08.2016 19:41, Robert Haas: > > 2. This inserts additional code in a bunch of really low-level places > like heap_hot_search_buffer, heap_update, heap_delete, etc. I think > what you've basically done here is create a new, in-memory heap AM and > then, because we don't have an API for adding new storage managers, > you've bolted it onto the existing heapam layer. That's certainly a > reasonable approach for creating a PoC, but I think we actually need a > real API here. Otherwise, when the next person comes along and wants > to add a third heap implementation, they've got to modify all of these > same places again. I don't think this code is reasonably maintainable > in this form. As I can see, you recommend to clean up the API of storage management code. I strongly agree that it's high time to do it. So, I started the discussion about refactoring and improving API of heapam and heap relations. You can find it on commitfest: https://commitfest.postgresql.org/10/700/ I'll be glad to see your thoughts on the thread. -- Anastasia Lubennikova Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
В списке pgsql-hackers по дате отправления: