Tom Lane wrote:
> 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.
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
Martijn van Oosterhout writes:
> The cost on inserting would generally go to either penalty, or
> picksplit. Certainly if you're inserting lots of values in a short
> interval, I can imagine picksplit being nasty, since the algorithms for
> a lot of datatypes are not really reknown for their speed
Stephan Vollmer <[EMAIL PROTECTED]> writes:
> 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.
I'd be willing to take a look, if you'll send
On Fri, Jan 20, 2006 at 10:35:21AM -0500, 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. It'd be interesting to look at a gprof profile of what the
> backend is doing during
Tom Lane wrote:
> Stephan Vollmer <[EMAIL PROTECTED]> writes:
>> I noticed that the creation of a GIST index for tsearch2 takes very
>> long - about 20 minutes. CPU utilization is 100 %, the resulting
>> index file size is ~25 MB. Is this behaviour normal?
>
> This has been complained of before.
Stephan Vollmer <[EMAIL PROTECTED]> writes:
> I noticed that the creation of a GIST index for tsearch2 takes very
> long - about 20 minutes. CPU utilization is 100 %, the resulting
> index file size is ~25 MB. Is this behaviour normal?
This has been complained of before. GIST is always going to b
PS:
What I forgot to mention was that inserting records into the table
is also about 2-3 times slower than before (most likely due to the
slow index update operations).
I dropped the whole database and restored the dumpfile, but the
result it the same. When the index is recreated after COPYing th
Hello!
I noticed that the creation of a GIST index for tsearch2 takes very
long - about 20 minutes. CPU utilization is 100 %, the resulting
index file size is ~25 MB. Is this behaviour normal?
Full text columns: title author_list
tsearch2 word lists: fti_title fti_author_list
tsea
