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 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
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
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 nu
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
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 contain
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 Scott!
Fri, 17 Dec 2010 19:06:15 -0700, you wrote:
> On Fri, Dec 17, 2010 at 10:32 AM, Craig James
> 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 RAID
>> controller card
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 Tom!
Thu, 21 Oct 2010 10:55:48 -0400, you wrote:
> Gael Le Mignot 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 lo
Hello Leonardo!
Thu, 21 Oct 2010 14:15:40 +0100 (BST), you wrote:
>> 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 solv
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 o
12 matches
Mail list logo
