Re: [HACKERS] Postgres Speed or lack thereof
От | Vadim Mikheev |
---|---|
Тема | Re: [HACKERS] Postgres Speed or lack thereof |
Дата | |
Msg-id | 36AC8D50.81E63F3@krs.ru обсуждение исходный текст |
Ответ на | Re: [HACKERS] Postgres Speed or lack thereof (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane wrote: > > 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. Ok, I agreed. Vadim
В списке pgsql-hackers по дате отправления: