[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgis-devel
Subject:    Re: [postgis-devel] && GIST operator - continued
From:       Dave Blasby <dblasby () refractions ! net>
Date:       2004-03-09 3:27:26
Message-ID: 1078802846.404d399e6f30a () hydra
[Download RAW message or body]

> 
> patch against postgis 0.8.1
> ************************************88
> --- postgis_gist_72.c.old   Fri Aug  8 14:19:20 2003
> +++ postgis_gist_72.c  Mon Mar  8 19:14:44 2004
> @@ -172,6 +172,8 @@
> 
>      result = rtree_internal_consistent((BOX *) DatumGetPointer(entry-
> >key), thebox, strategy );
> 
> +        pfree(thebox);
> +
>         PG_FREE_IF_COPY(query, 1);
>         PG_RETURN_BOOL(result);
>  }

This is similiar to what I did - I re-wrote the convert_box3d_to_box() 
function so it works "in situ" with a local BOX so you're not doing a palloc
()/pfree() every call.

Going from 90% to 40% CPU means you're I/O bound.  If you get faster drives 
(or raid 10 your disks) and you'll probably see it will run faster 
(palloc/pfree is slow).

You mentioned the compress function as another place it could be leaking.  Its 
more difficult to tell exactly how its leaking because the line:

gistentryinit(*retval, PointerGetDatum(r), entry->rel, entry->page,
					entry->offset, sizeof(BOX), FALSE);


hides when the actual BOX (r) gets written to disk and can be pfreed.  I'll 
have to look and see tomorrow.  

If you find/suspect any more leaks, let me know.

dave


[prev in list] [next in list] [prev in thread] [next in thread]