Re: [HACKERS] Postgres Speed or lack thereof
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Postgres Speed or lack thereof |
Дата | |
Msg-id | 18955.917277865@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Postgres Speed or lack thereof (Vadim Mikheev <vadim@krs.ru>) |
Список | pgsql-hackers |
Vadim Mikheev <vadim@krs.ru> writes: > Tom Lane wrote: >> I don't think we can or should stop using malloc(), but we can >> ask it for large blocks and do our own allocations inside those >> blocks --- was that what you meant? > No. We could ask brk() for large blocks. I think that would be a bad idea. brk() is a Unix-ism; I doubt it's supported on Win NT, for example. malloc() is a lot more portable. Another potential portability issue is whether malloc() will coexist with calling brk() ourselves. (It *ought* to, but I can believe that the feature might be broken on some platforms, since it's so seldom exercised...) We can't stop all uses of malloc(), because parts of the C library use it --- stdio, qsort, putenv all do on my machine. If we're going to grab large chunks and keep them, then any small inefficiency in doing the grabbing isn't really worth worrying about; so I don't see the need to bypass malloc() for that. regards, tom lane
В списке pgsql-hackers по дате отправления: