From: Steinar H. Gunderson <sgunderson@bigfoot.com>
To: pgsql-performance@postgresql.org
Subject: Re: [GENERAL] Creation of tsearch2 index is very slow
Date: Fri, 20 Jan 2006 23:57:51 +0100
Message-ID: <20060120225751.GA27230@uio.no> (raw)
In-Reply-To: <6111.1137797436@sss.pgh.pa.us>
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>
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/
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: sgunderson@bigfoot.com
Subject: Re: [GENERAL] Creation of tsearch2 index is very slow
In-Reply-To: <20060120225751.GA27230@uio.no>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox