Re: Single client performance on trivial SELECTs
От | Andres Freund |
---|---|
Тема | Re: Single client performance on trivial SELECTs |
Дата | |
Msg-id | 201104142234.57491.andres@anarazel.de обсуждение исходный текст |
Ответ на | Re: Single client performance on trivial SELECTs (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: Single client performance on trivial SELECTs
|
Список | pgsql-hackers |
On Thursday 14 April 2011 22:21:26 Alvaro Herrera wrote: > Excerpts from Andres Freund's message of jue abr 14 17:08:34 -0300 2011: > > Hi, > > > > On Thursday 14 April 2011 16:43:16 Tom Lane wrote: > > > I doubt that it's possible to make AllocSetAlloc radically cheaper. > > > > I actually doubt your doubt. I think you could add some SLAB like > > interface for common allocation sizes making it significantly faster for > > some uses (because allocation/deallocation is a single linked list > > operation). Maybe even treat everything < some_size as a slab object in > > the next bigger slab. > I think the problem with a slab allocator is that it would make > hierarchical context management slower and/or more complicated (e.g. > reset context on transaction abort). I am not that sure that it would be slower. I think that if youre careful you mostly can reuse what currently is done for chunks to implement slabs. For context resets you can just throw away all chunks/blocks. Where I am with you is that its quite possible that it will not make sense (performancewise) for all contexts. Which is quite annoying. Andres
В списке pgsql-hackers по дате отправления: