Re: Refactoring of heapam code.
От | Michael Paquier |
---|---|
Тема | Re: Refactoring of heapam code. |
Дата | |
Msg-id | CAB7nPqQJcASE63xhpD6_p5ouUy4Ak+jV_enBh-LSjghsx3cDwQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Refactoring of heapam code. (Pavan Deolasee <pavan.deolasee@gmail.com>) |
Список | pgsql-hackers |
On Mon, Sep 12, 2016 at 7:12 PM, Pavan Deolasee <pavan.deolasee@gmail.com> wrote: > I was thinking about locking, bulk reading (like page-mode API) etc. While > you've added an API for vacuuming, we would probably also need an API to > collect dead tuples, pruning etc (not sure if that can be combined with > vacuum). Of course, these are probably very specific to current > implementation of heap/MVCC and not all storages will need that. Likely not, but it is likely that people would like to be able to get that if some custom method needs it. I think that what would be a good first step here is to brainstorm a potential set of custom AMs for tables, get the smallest, meaningful, one from the set of ideas proposed, and define a basic set of relation/storage/table AM routines that we can come up to support it. And then build up a prototype using it. We have been talking a lot about refactoring and reordering stuff, which is something that would be good in the long term to make things more generic with heap, but getting an idea of "we-want-that" may prove to help in designing a minimum set if features that we'd like to have here. This would likely need anyway to extend CREATE TABLE to be able to pass a custom AM for a given relation and store in pg_catalog, but that's a detail in the whole picture... -- Michael
В списке pgsql-hackers по дате отправления: