Received: from localhost (unknown [200.46.208.211])
	by mail.postgresql.org (Postfix) with ESMTP id 42C6A635EA1
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Wed, 18 Mar 2009 17:21:50 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024)
	with ESMTP id 78878-03
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Wed, 18 Mar 2009 17:21:43 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by mail.postgresql.org (Postfix) with ESMTP id 30215635A00
	for <pgsql-performance@postgresql.org>;
	Wed, 18 Mar 2009 17:21:28 -0300 (ADT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id n2IKLQKo015056;
	Wed, 18 Mar 2009 16:21:27 -0400 (EDT)
To: Ron Mayer <rm_pg@cheapcomplexdevices.com>
cc: Oleg Bartunov <oleg@sai.msu.su>, Teodor Sigaev <teodor@sigaev.ru>,
	pgsql-performance@postgresql.org
Subject: Re: Extremely slow intarray index creation and inserts. 
In-reply-to: <49C11D6D.8020604@cheapcomplexdevices.com> 
References: <49BFD950.5040905@cheapcomplexdevices.com>
	<49BFEBD3.4000006@cheapcomplexdevices.com>
	<1804.1237346699@sss.pgh.pa.us>
	<49C11D6D.8020604@cheapcomplexdevices.com>
Comments: In-reply-to Ron Mayer <rm_pg@cheapcomplexdevices.com>
	message dated "Wed, 18 Mar 2009 09:12:29 -0700"
Date: Wed, 18 Mar 2009 16:21:26 -0400
Message-ID: <15055.1237407686@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0.011 tagged_above=0 required=5 tests=AWL=0.011
X-Spam-Level: 
X-Archive-Number: 200903/255
X-Sequence-Number: 33177

Ron Mayer <rm_pg@cheapcomplexdevices.com> writes:
> Oleg Bartunov wrote:
> OB:> it's not about short or long arrays, it's about small or big
> OB:> cardinality of the whole set (the number of unique elements)

> I'm re-reading the docs and still wasn't obvious to me.   A
> potential docs patch is attached below.

Done, though not in exactly those words.  I wonder though if we can
be less vague about it --- can we suggest a typical cutover point?
Like "use gist__intbig_ops if there are more than about 10,000 distinct
array values"?  Even a rough order of magnitude for where to worry
about this would save a lot of people time.

			regards, tom lane

Index: intarray.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/intarray.sgml,v
retrieving revision 1.5
retrieving revision 1.6
diff -c -r1.5 -r1.6
*** intarray.sgml	10 Dec 2007 05:32:51 -0000	1.5
--- intarray.sgml	18 Mar 2009 20:18:18 -0000	1.6
***************
*** 237,245 ****
    <para>
     Two GiST index operator classes are provided:
     <literal>gist__int_ops</> (used by default) is suitable for
!    small and medium-size arrays, while
     <literal>gist__intbig_ops</> uses a larger signature and is more
!    suitable for indexing large arrays.
    </para>
  
    <para>
--- 237,246 ----
    <para>
     Two GiST index operator classes are provided:
     <literal>gist__int_ops</> (used by default) is suitable for
!    small- to medium-size data sets, while
     <literal>gist__intbig_ops</> uses a larger signature and is more
!    suitable for indexing large data sets (i.e., columns containing
!    a large number of distinct array values).
    </para>
  
    <para>