From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Smith <greg(at)2ndquadrant(dot)com> |
Subject: | Re: Single client performance on trivial SELECTs |
Date: | 2011-04-14 20:34:57 |
Message-ID: | 201104142234.57491.andres@anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thursday 14 April 2011 22:21:26 Alvaro Herrera wrote:
> Excerpts from Andres Freund's message of jue abr 14 17:08:34 -0300 2011:
> > Hi,
> >
> > On Thursday 14 April 2011 16:43:16 Tom Lane wrote:
> > > I doubt that it's possible to make AllocSetAlloc radically cheaper.
> >
> > I actually doubt your doubt. I think you could add some SLAB like
> > interface for common allocation sizes making it significantly faster for
> > some uses (because allocation/deallocation is a single linked list
> > operation). Maybe even treat everything < some_size as a slab object in
> > the next bigger slab.
> I think the problem with a slab allocator is that it would make
> hierarchical context management slower and/or more complicated (e.g.
> reset context on transaction abort).
I am not that sure that it would be slower. I think that if youre careful you
mostly can reuse what currently is done for chunks to implement slabs.
For context resets you can just throw away all chunks/blocks.
Where I am with you is that its quite possible that it will not make sense
(performancewise) for all contexts. Which is quite annoying.
Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-04-14 20:46:03 | Re: Single client performance on trivial SELECTs |
Previous Message | Merlin Moncure | 2011-04-14 20:30:25 | Re: Single client performance on trivial SELECTs |