| От | Vadim B. Mikheev |
|---|---|
| Тема | Re: [HACKERS] Its not my fault. Its SEG's FAULT! |
| Дата | |
| Msg-id | 352470D4.C32F5BD3@sable.krasnoyarsk.su обсуждение исходный текст |
| Ответ на | Re: [HACKERS] Its not my fault. Its SEG's FAULT! ("Maurice Gittens" <mgittens@gits.nl>) |
| Ответы |
Re: [HACKERS] Its not my fault. Its SEG's FAULT!
|
| Список | pgsql-hackers |
I agreed with Maurice. Using GC instead of MemoryDuration everywhere isn't good idea for database server. But we could implement additional GC-like allocation mode and use it where is appropriate! One example - using float8 (etc) in WHERE. We could switch to GC-allocation in the beginnig of ExecQual () and destroy all allocations made in GC-mode before return(). Another example - psort.c! With -S 8192 I see that server uses ~ 30M of memory - due to malloc/palloc overhead in palloc() for each tuple. No one of these allocations will be freed untill psort_end() <- good place for GC-destroyer. Comments ? Vadim
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера