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 | CAGTBQpYuLee8NEzjbp6nP6RhnPPF5aQ+ntejUVjsu0nR0iFZqg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Vacuum: allow usage of more than 1GB of work mem (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Wed, Sep 14, 2016 at 12:17 PM, Robert Haas <robertmhaas@gmail.com> wrote: > For instance, one idea to grow memory usage incrementally would be to > store dead tuple information separately for each 1GB segment of the > relation. So we have an array of dead-tuple-representation objects, > one for every 1GB of the relation. If there are no dead tuples in a > given 1GB segment, then this pointer can just be NULL. Otherwise, it > can point to either the bitmap representation (which will take ~4.5MB) > or it can point to an array of TIDs (which will take 6 bytes/TID). > That could handle an awfully wide variety of usage patterns > efficiently; it's basically never worse than what we're doing today, > and when the dead tuple density is high for any portion of the > relation it's a lot better. If you compress the list into a bitmap a posteriori, you know the number of tuples per page, so you could encode the bitmap even more efficiently. It's not a bad idea, one that can be slapped on top of the multiarray patch - when closing a segment, it can be decided whether to turn it into a bitmap or not.
В списке pgsql-hackers по дате отправления: