On Thu, Aug 16, 2012 at 09:51:28PM -0400, Stephen Frost wrote:
> Bruce,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > Did we make any headway on this?
>
> I've got the code written but I need to test it in a stable environment
> to see what kind of improvment it provides. I've actually been
Bruce,
* Bruce Momjian (br...@momjian.us) wrote:
> Did we make any headway on this?
I've got the code written but I need to test it in a stable environment
to see what kind of improvment it provides. I've actually been fighting
for the past 2 months with the box that I want to use and think I ma
Is this a TODO?
---
On Sat, Nov 19, 2011 at 12:31:09PM -0500, Stephen Frost wrote:
> Andres,
>
> * Andres Freund (and...@anarazel.de) wrote:
> > For that I added new functions/defines which allocate all the needed memory
>
Did we make any headway on this?
---
On Sat, Nov 19, 2011 at 12:31:09PM -0500, Stephen Frost wrote:
> Andres,
>
> * Andres Freund (and...@anarazel.de) wrote:
> > For that I added new functions/defines which allocate all the
On Sat, Nov 19, 2011 at 12:33 PM, Stephen Frost wrote:
> You've mentioned that before and, to be honest, I could have sworn that
> we're doing that already..
I tried to write a patch for that at one point, but it crashed and
burned over the exact same set of issues discussed upthread, which I
was
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Now, if you could do something that *doesn't* restrict what operations
> could be applied to the lists, that would be good.
If the API is followed, I believe my previous patch works for
everything, but it wasn't variable about the size of the new list.
Perh
Andres,
* Andres Freund (and...@anarazel.de) wrote:
> For that I added new functions/defines which allocate all the needed memory
> in
> one hunk:
> list_immutable_make$n(),
> List *list_new_immutable_n(NodeTag t, size_t n);
> List *list_make_n(NodeTag t, size_t n, ...);
A while back, I posted
On Friday, November 18, 2011 10:11:29 PM Tom Lane wrote:
> Andres Freund writes:
> > In many scenarios memory allocation is one of the top 3 functions showing
> > up in profiles. Looking at hierarchical profiles
> > (-fno-omit-frame-pointer) at least during parsing, planning and executor
> > start
Andres Freund writes:
> In many scenarios memory allocation is one of the top 3 functions showing up
> in profiles. Looking at hierarchical profiles (-fno-omit-frame-pointer) at
> least
> during parsing, planning and executor startup most of that is spent around
> the
> list API.
> Many - es
Hi List,
In many scenarios memory allocation is one of the top 3 functions showing up
in profiles. Looking at hierarchical profiles (-fno-omit-frame-pointer) at
least
during parsing, planning and executor startup most of that is spent around the
list API.
Many - especially in the parse-analyz
10 matches
Mail list logo