On Sat, Sep 13, 2003, Tom Lane wrote:
> David Schultz <[EMAIL PROTECTED]> writes:
> > While looking into a block size mismatch problem between
> > Postgresql and FreeBSD's FFS, I noticed that postgresql is making
> > some rather odd-sized requests to malloc(3): 0x2034, 0x2020,
> > 0x4018, 0x8018, e
David Schultz <[EMAIL PROTECTED]> writes:
> ... I assume that pgsql will be able to use the
> slack allocated in each chunk.
That's the theory, anyway. Undoubtedly the extra allocation will go to
waste in some scenarios, but we're no worse off than we were before.
regards
David Schultz <[EMAIL PROTECTED]> writes:
> While looking into a block size mismatch problem between
> Postgresql and FreeBSD's FFS, I noticed that postgresql is making
> some rather odd-sized requests to malloc(3): 0x2034, 0x2020,
> 0x4018, 0x8018, etc. Most malloc(3) implementations round large
David Schultz <[EMAIL PROTECTED]> writes:
> While looking into a block size mismatch problem between
> Postgresql and FreeBSD's FFS, I noticed that postgresql is making
> some rather odd-sized requests to malloc(3): 0x2034, 0x2020,
> 0x4018, 0x8018, etc.
AFAICT the operative word there is "some" -
While looking into a block size mismatch problem between
Postgresql and FreeBSD's FFS, I noticed that postgresql is making
some rather odd-sized requests to malloc(3): 0x2034, 0x2020,
0x4018, 0x8018, etc. Most malloc(3) implementations round large
allocations up to a multiple of a large power of 2
