Stephan Vollmer <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> However, I'm not sure that anyone's tried to do any performance >> optimization on the GIST insert code ... there might be some low-hanging >> fruit there.
> Unfortunately, I'm not able to investigate it further myself as I'm > quite a Postgres newbie. But I could provide someone else with the > example table. Maybe someone else could find out why it is so slow. The problem seems to be mostly tsearch2's fault rather than the general GIST code. I've applied a partial fix to 8.1 and HEAD branches, which you can find here if you're in a hurry for it: http://archives.postgresql.org/pgsql-committers/2006-01/msg00283.php (the gistidx.c change is all you need for tsearch2) There is some followup discussion in the pgsql-performance list. It seems possible that we can get another factor of 10 or better with a smarter picksplit algorithm --- but that patch will probably be too large to be considered for back-patching into the stable branches. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
