| 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: | Whole Thread | Raw Message | 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 |