Would it be OK if I went through here and hacked on the comments and
sent this back to you?
Feel free to edit the patch.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-h
2010/1/24 Teodor Sigaev :
>> 3. This code could really use some more comments, and maybe some of
>> the variable names could be better chosen, too. It's far from obvious
>> what is going on here. I studied rbtrees in college and I still
>> remember more or less how they work, but, boy, this is ha
1. I think rb_free_recursive is missing a pfree().
Fixed, thank you
2. We already have a definition of NIL in the PG source base. I think
this one needs to be named something else. RBNIL, maybe.
fixed
3. This code could really use some more comments, and maybe some of
the variable names
On Mon, Jan 11, 2010 at 1:18 PM, Robert Haas wrote:
> 2010/1/11 Teodor Sigaev :
>> knngist uses that implementation of rb-tree. One more candidate is a ts_stat
>> which now uses unbalanced binary tree.
>
> Ah, OK. That's great if we can reuse that code in 2 or 3 places.
Some preliminary thoughts
2010/1/11 Teodor Sigaev :
> knngist uses that implementation of rb-tree. One more candidate is a ts_stat
> which now uses unbalanced binary tree.
Ah, OK. That's great if we can reuse that code in 2 or 3 places.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
...and I would say the same logic applies to this patch, maybe even
moreso. Tom has already applied a partial workaround for this
problem, and I'm feeling like it won't be trivial to figure out what
That partial workaround is not work for some corner cases:
http://www.sai.msu.su/~megera/wiki/20
Robert,
we have benchmark for rbtree
http://www.sai.msu.su/~megera/wiki/2009-07-27
rbtree, actually, fix corner cases with ordered input, with little
overhead.
As you may see from knngist patch, rbtree used in gist code, so, please,
leave rbtree code as is.
Oleg
On Sun, 10 Jan 2010, Robert Haas
On Mon, Jan 11, 2010 at 2:42 AM, Robert Haas wrote:
> The coding pattern that this patch uses also merits some discussion.
> Basically, rbtree.c is a generic implementation of red-black trees -
> from a textbook - which ginbulk.c then uses for GIN. One possible
> advantage of this implementation
On Thu, Dec 31, 2009 at 4:19 PM, Robert Haas wrote:
> My other question is as related to performance. Can you provide a
> test case that shows the performance improvement with this patch?
So, we still don't have a test case for this patch. During the
November CommitFest, Greg Smith griped a bit
On Mon, Jan 4, 2010 at 8:12 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> I did a quick read-through of this, and one question that immediately
>> occurred to me is that rbtree.c says that it is adopted from
>> http://algolist.manual.ru/ds/rbtree.php. But I'm not sure what
>> license that
Robert Haas escribió:
> I did a quick read-through of this, and one question that immediately
> occurred to me is that rbtree.c says that it is adopted from
> http://algolist.manual.ru/ds/rbtree.php. But I'm not sure what
> license that code is under, so I'm not sure whether it's OK for us to
> u
2009/11/23 Teodor Sigaev :
> Hi there,
>
> attached is a patch, which contains implementation of a red-black
> tree, a self-balanced implementation of binary tree. The main goal of
> this patch is to improve creation time of GIN index in the corner cases.
> While creation, GIN collects data in m
Hi there,
attached is a patch, which contains implementation of a red-black
tree, a self-balanced implementation of binary tree. The main goal of
this patch is to improve creation time of GIN index in the corner cases.
While creation, GIN collects data in memory in binary tree until it
reach s
13 matches
Mail list logo
