Re: [CFReview] Red-Black Tree

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Teodor Sigaev <teodor(at)sigaev(dot)ru>, Mark Cave-Ayland <mark(dot)cave-ayland(at)siriusit(dot)co(dot)uk>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [CFReview] Red-Black Tree
Date: 2010-02-09 14:02:11
Message-ID: 20100209140211.GA5522@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas escribió:
> On Mon, Feb 8, 2010 at 3:05 PM, Alvaro Herrera
> <alvherre(at)commandprompt(dot)com> wrote:

> > How do we now that it works?
>
> Visual inspection? It's not very complicated.

Well, that works if you assume the trivial/usual malloc/free coding
style, but it fails in the hypothetical scenario I described earlier.
You could as well say that each rbtree must provide a memory context
that is going to be deleted when the tree is freed, instead of freeing
nodes one by one (and in fact it looks more efficient to do it that way
... except that we'd have to get in the business of strcpy'ing the
node's data). There's no way to know how this stuff is going to be
used, so if it's not going to be used now, I think we shouldn't
implement it. That's why I looked at the knngist patch too.

But hey, not that i care all that much either -- it's not a lot of code;
a couple dozen lines at most, and not complex.

> > (What, for example, if we were to allocate multiple nodes in a single
> > palloc chunk?  I'm not familiar with this stuff but that seems
> > plausible)
>
> Well, then you could have the freefunc do something ((MyStruct *)
> a)->is_allocated = false.

Hmm, but isn't "a" gone at that point?

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2010-02-09 14:10:22 Re: Avoiding bad prepared-statement plans.
Previous Message Tollef Fog Heen 2010-02-09 13:57:24 Re: TCP keepalive support for libpq