Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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                      
The PostgreSQL Company - Command Prompt, Inc.

In response to

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group