From: | Vadim Mikheev <vadim(at)krs(dot)ru> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Postgres Speed or lack thereof |
Date: | 1999-01-25 15:27:12 |
Message-ID: | 36AC8D50.81E63F3@krs.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
>
> 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.
Ok, I agreed.
Vadim
From | Date | Subject | |
---|---|---|---|
Next Message | Oleg Broytmann | 1999-01-25 15:34:26 | Re: [HACKERS] Re: datetime regress test busted by incomplete checkin |
Previous Message | Tom Lane | 1999-01-25 15:24:25 | Re: [HACKERS] Postgres Speed or lack thereof |