Re: [HACKERS] Postgres Speed or lack thereof - Mailing list pgsql-hackers

From Vadim Mikheev
Subject Re: [HACKERS] Postgres Speed or lack thereof
Date
Msg-id 36AC8D50.81E63F3@krs.ru
Whole thread Raw
In response to Re: [HACKERS] Postgres Speed or lack thereof  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Postgres Speed or lack thereof
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] postgres (zombie)