Re: equal() perf tweak - Mailing list pgsql-patches

From Gaetano Mendola
Subject Re: equal() perf tweak
Date
Msg-id 3FA9952D.8080202@bigfoot.com
Whole thread Raw
In response to Re: equal() perf tweak  (Neil Conway <neilc@samurai.com>)
Responses Re: equal() perf tweak
List pgsql-patches
Neil Conway wrote:
> Ok, I've attached new versions of list.c and pg_list.h -- this is just a
> *rough sketch* of the new List code -- it definitely won't compile, the
> intent is just to concretely specify the new List design. Also, I've
> only updated the important list functions: I stopped at nth().
>
> (I've attached the whole files, rather than diffs, because I thought
> that would be easier to read...)
>
> Any comments would be welcome -- I'm sure I've mucked a few things up.
> Also, since it doesn't compile and I haven't done any testing, there are
> probably some thinkos & typos in the code.
>
> On Tue, 2003-11-04 at 11:40, Tom Lane wrote:
>
>>Hmm ... taking that one step further, you could probably avoid the need
>>for two palloc's in the first lcons/lappend if the List header were
>>combined with the first ListCell.  This would make for some grottiness
>>in ldelete when removing the first list entry, but that's probably
>>a good tradeoff.
>
>
> I haven't implemented this (yet), or the aset.c changes you suggested.

Why instead of reinvent the whell not use, or at least do a "C" port of
stl::list ? At my knowledge is the best/optimized list implementation.

And another my wish is too see Postgres compilable with a c++ compiler
so a day we can use ( in a absolutely portable way):  vector, list, map
already implemented, considering also the fact that all stl container
are "memory allocator" customizable, for example you can use a map using
an allocator in shared memory.



Regards
Gaeatano Mendola


PS: My 2 cents: I don't like too much have the lenght inside the list
struct.




pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: equal() perf tweak
Next
From: Neil Conway
Date:
Subject: Re: equal() perf tweak