Re: pgsql: Avoid creation of the free space map for small heaprelations, t
| От | Amit Kapila |
|---|---|
| Тема | Re: pgsql: Avoid creation of the free space map for small heaprelations, t |
| Дата | |
| Msg-id | CAA4eK1LbNP+k3WQihzXFqWU6oVOx3A3XeVr9vGTdMCc2et3V8g@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: pgsql: Avoid creation of the free space map for small heap relations, t (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
On Mon, Feb 25, 2019 at 11:14 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > I wrote: > > Amit Kapila <akapila@postgresql.org> writes: > >> Avoid creation of the free space map for small heap relations, take 2. > > > I think this patch still has some issues. > > Just out of curiosity ... how can it possibly be even a little bit sane > that fsm_local_map is a single static data structure, without even any > indication of which table it is for? > It is just for finding a free block among a few blocks of relation. We clear this when we have found a block with enough free space, when we extend the relation, or on transaction abort. So, I think we don't need any per table information. > If, somehow, there's a rational argument for that design, why is it > not explained in freespace.c? The most charitable interpretation of > what I see there is that it's fatally undercommented. > There is some explanation in freespace.c and in README (src/backend/storage/freespace/README). I think we should add some more information where this data structure (FSMLocalMap) is declared. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: