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's 8.4 from Debian Squeeze.
> 8.4.what?
It's 8.4.8-0squeeze1
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's 8.4 from Debian Squeeze.
8.4.what?
In particular I'm wondering if you need this 8.4.6 fix:
http://git.postgresql.org/gitweb/?p=
On 9/07/2011 4:43 PM, Gael Le Mignot wrote:
maintenance_work_mem is at 16Mb, shared_buffers at 24Mb.
Woah, what? And you're hitting a gigabyte for autovacuum? Yikes. That
just doesn't sound right.
Are you using any contrib modules? If so, which ones?
Are you able to post your DDL?
How big
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
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 configuration, and unless I'm wrong, it shouldn't take
> > more than
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
On Sat, 2011-07-09 at 10:43 +0200, Gael Le Mignot wrote:
> 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
> >> lo
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,
>>
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 t
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 of the two tables contains a gin full-text index.
>
> We noticed th
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 contains a gin full-text index.
We noticed that the autovacuum proce
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
13 matches
Mail list logo
