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 36ABDE93.50A3E69A@krs.ru
Whole thread Raw
In response to Re: [HACKERS] Postgres Speed or lack thereof  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Postgres Speed or lack thereof  (Vince Vielhaber <vev@michvhf.com>)
Re: [HACKERS] Postgres Speed or lack thereof  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [HACKERS] Postgres Speed or lack thereof  (Massimo Dal Zotto <dz@cs.unitn.it>)
List pgsql-hackers
Tom Lane wrote:
> 
> > Note that our mmgr adds 16 bytes to each allocation
> > (+ some bytes in malloc) - a great overhead, yes?
> 
> Youch ... for a list-node-sized request, that's a lot of overhead.

And lists are very often used by planner and - never pfreed.

> Getting this right is probably going to take some thought and work,
> but it looks worthwhile from a performance standpoint.  Maybe for 6.6?

Yes - I have to return to MVCC stuff...
So, I consider my exercizes with mmgr as vacation from MVCC -:)

> > It shows that we should get rid of system malloc/free and do
> > all things in mmgr itself - this would allow us much faster
> > free memory contexts at statement/transaction end.
> 
> 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.
The problem is where to handle dynamic allocations.
As long as they are handled by malloc we can't put
them in proper blocks of current memory context.
But having our own handling malloc would become useless.

Vadim


pgsql-hackers by date:

Previous
From: "Thomas G. Lockhart"
Date:
Subject: Re: Odd behavior of type coercion for datetime
Next
From: Vince Vielhaber
Date:
Subject: Re: [HACKERS] Postgres Speed or lack thereof