Hi All,
I am having a problem with getting tsearch2 installed and working. And
before I start, I know that postgresql 8.2 will be end of lifed at the end of
this year. We can't move to a newer version for support reasons :( . This
postgresql instance will be a backup of the main instance,
wrote:
> I built a database on postgres8.1, then I did VACUUM FULL ANALYZE, but
> the query is still slow.
> Has anybody an idea ?
When I had performance problems, what I did was go through the specific
queries that we presenting the performance problem and used an analyze on
those queries.
You might be able to do that will slony (haven't tried) and you might be even
be able to get away with a view
into the data depending on your requirements. -Tino
From: pgsql-admin-ow...@postgresql.org [pgsql-admin-ow...@postgresql.org] On
Behalf Of dimita
: Dai, Tino; pgsql-admin@postgresql.org
Subject: [ADMIN] Ubuntu 10.04 - Cannot Create TCP/IP Sockets
Good evening.
I've recently provisioned a new Ubuntu 10.04 server. I ran "apt-get
install postgresql-8.4", just like I normally do when I'm setting up a
new server. However, this
n
find.
-Tino
From: pgsql-admin-ow...@postgresql.org [pgsql-admin-ow...@postgresql.org] On
Behalf Of Greg Smith [g...@2ndquadrant.com]
Sent: Tuesday, March 30, 2010 1:05 PM
To: Dai, Tino; Renato Oliveira
Cc: pgsql-admin@postgresql.org; Tino Schwarze
Subject: Re: [ADMIN] Migrate po
Hi Tom,
> Is that really the first error you got? It looks like you've neglected
> to provide contrib/tsearch2 in the new installation.
I actually double checked that I did have the tsearch2.so in my pgsql/lib
directory.
What I was doing was not running the tsearch2.sql in the share/contrib
di
Hi!
I shut down the database to upgrade from 8.1.11 to 8.2.16. We use pg_dump
to dump and psql with the < sign to restore. But I had a problem with restoring
the
dump. I got a
ERROR: function "snb_ru_init(internal)" does not exist
CONTEXT: COPY pg_ts_dict, line 3, column dict_init: "snb_ru
> 8.2 was released in 2006. 8.1 is going to be desupported entirely at
> the end of 2010. You really need to be holding your vendor's feet to
> the fire about supporting modern versions of Postgres, rather than
> looking for workarounds.
I think that is the correct move.
>> But having said tha
After many days of googling and referring to different web pages about
performance, I'm
turning to this list for help. We have a third party application that is
running on 8.1.11 and the
vendor has told us not to upgrade the database to 8.2.
I have gone with the default values in postgresql.con
