Date: Fri, 20 Jan 2006 23:57:51 +0100
From: "Steinar H. Gunderson" <sgunderson@bigfoot.com>
To: pgsql-performance@postgresql.org
Subject: Re: [GENERAL] Creation of tsearch2 index is very slow
Message-ID: <20060120225751.GA27230@uio.no>
Mail-Followup-To: pgsql-performance@postgresql.org
References: <17454.1137771321@sss.pgh.pa.us>
 <20060120170452.GC31908@svana.org>
	<26153.1137784469@sss.pgh.pa.us> <20060120201036.GE31908@svana.org>
	<26583.1137788505@sss.pgh.pa.us> <20060120205132.GF31908@svana.org>
	<26958.1137791955@sss.pgh.pa.us> <20060120213754.GG31908@svana.org>
	<7.0.1.0.2.20060120174141.039b03e8@earthlink.net>
	<6111.1137797436@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <6111.1137797436@sss.pgh.pa.us>
User-Agent: Mutt/1.5.11

On Fri, Jan 20, 2006 at 05:50:36PM -0500, Tom Lane wrote:
> Yeah, but fetching from a small constant table is pretty quick too;
> I doubt it's worth getting involved in machine-specific assembly code
> for this.  I'm much more interested in the idea of improving the
> furthest-distance algorithm in gtsvector_picksplit --- if we can do
> that, it'll probably drop the distance calculation down to the point
> where it's not really worth the trouble to assembly-code it.

For the record: Could we do with a less-than-optimal split here? In that
case, an extremely simple heuristic is:

  best = distance(0, 1)
  best_i = 0
  best_j = 1

  for i = 2..last:
      if distance(best_i, i) > best:
          best = distance(best_i, i)
	  best_j = i
      else if distance(best_j, i) > best:
          best = distance(best_j, i)
	  best_i = i

I've tested it on various data, and although it's definitely not _correct_,
it generally gets within 10%.

/* Steinar */
-- 
Homepage: http://www.sesse.net/