Thread: GiST memory usage
Hi all. I've been reported memory limit hits during a postgis index construction (GiST index). The indexed tuples are about 425 millions. The index key is a box2d object (4*sizeof(float)). The machine has 4 Gb of RAM, and operations are peaked at ~2.4 Gb of usage. Is there a way to detect where is memory hold ? Is there an index-specific memory context for use to early release memory blocks allocated during operations (didn't see any use of memory contexts in the contrib/rtree_gist) ? TIA --strk;
Missing info for the report:win32postgresql 8.0.3maintenance_work_mem 512btree index on oid works fine --strk; On Sat, Aug 13, 2005 at 01:12:30PM +0200, strk@refractions.net wrote: > Hi all. > I've been reported memory limit hits > during a postgis index construction > (GiST index). > > The indexed tuples are about 425 millions. > The index key is a box2d object (4*sizeof(float)). > > The machine has 4 Gb of RAM, and operations are > peaked at ~2.4 Gb of usage. > > Is there a way to detect where is memory hold ? > > Is there an index-specific memory context for use > to early release memory blocks allocated during > operations (didn't see any use of memory contexts > in the contrib/rtree_gist) ? > > TIA > > --strk;
> Is there a way to detect where is memory hold ? Look at postgis code. We constructed rtree_gist index over 1e9 rows (on 8.0 pgsql). > > Is there an index-specific memory context for use > to early release memory blocks allocated during > operations (didn't see any use of memory contexts > in the contrib/rtree_gist) ? 8.1 pgsql has short lived memory context during index creation which resets after every insert. 8.0 hasn't this feature, so user-defined function (GiST interfface) should carefully clean memory. -- Teodor Sigaev E-mail: teodor@sigaev.ru WWW: http://www.sigaev.ru/