On Fri, Sep 16, 2011 at 19:16, Tom Lane wrote:
>
> Stephan Vollmer writes:
> > I upgraded our test database from PostgreSQL 8.4.8 to 9.0.4 via pg_dumpall.
> > The database seems to work fine, but now the logfile of the new database is
> > flooded with log messages like th
Hi,
I upgraded our test database from PostgreSQL 8.4.8 to 9.0.4 via pg_dumpall.
The database seems to work fine, but now the logfile of the new database is
flooded with log messages like these:
2011-09-16 13:48:32 CEST: LOG: database system was shut down at 2011-09-16
13:48:29 CEST
2011-09-16 13
Sorry for the late reply, I didn't have much time during the last
days to catch up on this list.
Merlin Moncure wrote:
> try turning row level statistics off (or, during bulk inserts, turn
> inserts off completely). I've seem this too but never nailed it down.
Thanks, I'll give that a try!
- S
Hello!
In my PostgreSQL logfile, I see that the following entries occur
very frequently:
2006-01-27 10:37:29 FATAL could not read from statistics collector
pipe: No error
2006-01-27 10:37:30 LOGstatistics collector process (PID 5940)
was
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.
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?
>
> T
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
Andrew J. Kopciuch wrote:
>>You could write a one trigger for the table to handle both.
>
> Something like this :
[...]
> CREATE OR REPLACE FUNCTION multi_tsearch2() RETURNS TRIGGER AS '
[...]
I tested the function today and it's exactly what I had in mind.
Works perfectly!
Thanks, Stephan
sign
[Andrew, sorry for the PM - I pressed the wrong button.]
Andrew J. Kopciuch wrote:
>>You could write a one trigger for the table to handle both.
>
> Something like this :
[...]
> You can modify the function to be slightly more configurable with parameters
> taking the column names, and config
Hi all,
is it possible to index 2 columns in a table with tsearch2 using
different configurations for each column index?
I have a table publications that is defined as follows (simplified):
CREATE TABLE publications
(
title text,
author_list text,
fti_title tsvector,
Hi!
CSN wrote:
> I'm thinking of enabling searches that use queries like "select *
> from items where title ilike '%term%'". The items table has tens
> of thousands of rows. Is it worth worrying about the performance
> of such a query (since, if I'm not mistaken, it will never use
> indices). If i
12 matches
Mail list logo
