Hello,
Here is an update on my problem :
- the problem was caused by VACUUM ANALYZE, but by a plain VACUUM ;
- it was exactly the same with manual and automatic VACUUM ANALYZE ;
- it was caused by a GIN index on a tsvector, using a very high (1)
statistics target.
Setting back the
Hello Tom!
Sat, 09 Jul 2011 12:23:18 -0400, you wrote:
Gael Le Mignot g...@pilotsystems.net writes:
Sat, 09 Jul 2011 11:06:16 +0200, you wrote:
BTW, what's your PostgreSQL release? I assume at least 8.3 since you're
using FTS?
It's 8.4 from Debian Squeeze.
8.4.what?
It's 8.4.8
Hello,
We are running a PostgreSQL 8.4 database, with two tables containing a
lot ( 1 million) moderatly small rows. It contains some btree indexes,
and one of the two tables contains a gin full-text index.
We noticed that the autovacuum process tend to use a lot of memory,
bumping the
Hello Craig!
Sat, 09 Jul 2011 16:31:47 +0800, you wrote:
On 9/07/2011 3:25 PM, Gael Le Mignot wrote:
Hello,
We are running a PostgreSQL 8.4 database, with two tables containing a
lot ( 1 million) moderatly small rows. It contains some btree indexes,
and one of the two tables
Hello Guillaume!
Sat, 09 Jul 2011 10:33:03 +0200, you wrote:
Hi,
On Sat, 2011-07-09 at 09:25 +0200, Gael Le Mignot wrote:
[...]
We are running a PostgreSQL 8.4 database, with two tables containing a
lot ( 1 million) moderatly small rows. It contains some btree indexes,
and one
Hello Guillaume!
Sat, 09 Jul 2011 10:53:14 +0200, you wrote:
I don't quite understand how you can get up to 1GB used by your process.
According to your configuration, and unless I'm wrong, it shouldn't take
more than 40MB. Perhaps a bit more, but not 1GB. So, how did you find
this
Hello Guillaume!
Sat, 09 Jul 2011 11:06:16 +0200, you wrote:
On Sat, 2011-07-09 at 11:00 +0200, Gael Le Mignot wrote:
Hello Guillaume!
Sat, 09 Jul 2011 10:53:14 +0200, you wrote:
I don't quite understand how you can get up to 1GB used by your process.
According to your
Hello Scott!
Fri, 17 Dec 2010 19:06:15 -0700, you wrote:
On Fri, Dec 17, 2010 at 10:32 AM, Craig James
craig_ja...@emolecules.com wrote:
RAID5 is a Really Bad Idea for any database. It is S...L...O...W. It does
NOT give better redundancy and security; RAID 10 with a battery-backed
Hello,
Thanks to everyone who gave me hints and feedbacks. I managed to solve
the problem.
My understanding of what was happening is the following :
- The gin index (as explained on [1]), stores temporary list, and when
they grow big enough, those are dispatched into the real index. Vacuum
Hello,
We are using PostgreSQL for storing data and full-text search indexes
for the webiste of a daily newspaper. We are very happy overall with the
results, but we have one weird behaviour that we would like to solve.
The problem is when we index objects into the full-text search part of
Hello Tom!
Thu, 21 Oct 2010 10:55:48 -0400, you wrote:
Gael Le Mignot g...@pilotsystems.net writes:
The problem is when we index objects into the full-text search part of
the database (which a DELETE and then an INSERT into a specific table),
the INSERT sometimes take a long time
11 matches
Mail list logo
