Re: equal() perf tweak
От | Gaetano Mendola |
---|---|
Тема | Re: equal() perf tweak |
Дата | |
Msg-id | 3FA9952D.8080202@bigfoot.com обсуждение исходный текст |
Ответ на | Re: equal() perf tweak (Neil Conway <neilc@samurai.com>) |
Ответы |
Re: equal() perf tweak
|
Список | 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 по дате отправления: