Re: Vacuum: allow usage of more than 1GB of work mem
От | Claudio Freire |
---|---|
Тема | Re: Vacuum: allow usage of more than 1GB of work mem |
Дата | |
Msg-id | CAGTBQpak611uw9mE+7SvbEQ-x3pusyOQkFH_rCLj-Yw5QtE-dg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Vacuum: allow usage of more than 1GB of work mem (Pavan Deolasee <pavan.deolasee@gmail.com>) |
Ответы |
Re: Vacuum: allow usage of more than 1GB of work mem
|
Список | pgsql-hackers |
On Thu, Sep 8, 2016 at 11:54 AM, Pavan Deolasee <pavan.deolasee@gmail.com> wrote: > For example, for a table with 60 bytes wide tuple (including 24 byte > header), each page can approximately have 8192/60 = 136 tuples. Say we > provision for 136*2 = 272 bits per page i.e. 34 bytes per page for the > bitmap. First 272 offsets in every page are represented in the bitmap and > anything greater than are in overflow region. On the other hand, the current > representation will need about 16 bytes per page assuming 2% dead tuples, 40 > bytes per page assuming 5% dead tuples and 80 bytes assuming 10% dead > tuples. So bitmap will take more space for small tuples or when vacuum is > run very aggressively, both seems unlikely for very large tables. Of course > the calculation does not take into account the space needed by the overflow > area, but I expect that too be small. I thought about something like this, but it could be extremely inefficient for mostly frozen tables, since the bitmap cannot account for frozen pages without losing the O(1) lookup characteristic
В списке pgsql-hackers по дате отправления: