Stephan Vollmer <svollmer@gmx.de> 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
