From: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Red-black tree for GIN |
Date: | 2010-01-11 18:08:43 |
Message-ID: | 4B4B692B.4050401@sigaev.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> ...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/2009-07-27 (8.4 already has that hask!)
> 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 is that it might make it possible for
> us to use the rbtree.c logic in other places, if we have other data
> structures that need similar treatment. But I'm not sure if that's
> the way we want to go. The other alternative is to drop the
> generalized implementation and incorporate the logic directly into
> ginbulk.c. I really don't know which is better, but I'd like to hear
> some other opinions...
knngist uses that implementation of rb-tree. One more candidate is a ts_stat
which now uses unbalanced binary tree.
--
Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-01-11 18:17:25 | Re: point_ops for GiST |
Previous Message | Teodor Sigaev | 2010-01-11 17:57:18 | Re: point_ops for GiST |