Re: [HACKERS] Postgres Speed or lack thereof

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Vadim Mikheev <vadim(at)krs(dot)ru>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Postgres Speed or lack thereof
Date: 1999-01-25 15:24:25
Message-ID: 18955.917277865@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Vadim Mikheev <vadim(at)krs(dot)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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Vadim Mikheev 1999-01-25 15:27:12 Re: [HACKERS] Postgres Speed or lack thereof
Previous Message Bruce Momjian 1999-01-25 15:11:52 Re: [HACKERS] Re: datetime regress test busted by incomplete checkin