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

Re: GiST index performance

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Matthew Wakeling <matthew(at)flymine(dot)org>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-performance(at)postgresql(dot)org, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Teodor Sigaev <teodor(at)sigaev(dot)ru>
Subject: Re: GiST index performance
Date: 2009-04-20 15:27:00
Message-ID: 6704.1240241220@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-performance
Matthew Wakeling <matthew(at)flymine(dot)org> writes:
> I have found a bug in the contrib package seg, which has been copied into 
> the bioseg data type as well. It causes the index to be created with 
> horribly bad unselective trees, so that when a search is performed many of 
> the branches of the tree need to be followed. This explanation does not 
> extend to btree_gist, so I will have to further investigate that. Apply 
> the following patch to contrib/seg/seg.c:

> *** seg.c	2006-09-10 18:36:51.000000000 +0100
> --- seg.c_new	2009-04-20 15:02:52.000000000 +0100
> ***************
> *** 426,432 ****
>    		else
>    		{
>    			datum_r = union_dr;
> ! 			size_r = size_alpha;
>    			*right++ = i;
>    			v->spl_nright++;
>    		}
> --- 426,432 ----
>    		else
>    		{
>    			datum_r = union_dr;
> ! 			size_r = size_beta;
>    			*right++ = i;
>    			v->spl_nright++;
>    		}

Looks like contrib/cube has the same error.  I don't see a similar code
pattern elsewhere though.  Oleg, Teodor, do you concur that this is a
correct patch?  Is it safe to back-patch (I think it should be)?

			regards, tom lane

In response to

Responses

pgsql-performance by date

Next:From: Rafael DomicianoDate: 2009-04-20 18:48:28
Subject: Re: SQL With Dates
Previous:From: Grzegorz JaƛkiewiczDate: 2009-04-20 14:14:15
Subject: Re: SQL With Dates

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