Heikki Linnakangas writes:
> On 09.07.2011 00:36, Anish Kejariwal wrote:
>> My guess as to what happened:
>> -because the icecream parent table has zero records, the query optimizer
>> chooses the incorrect execution plan
>> -when I do select * from icecream, the optimizer now knows how many recor
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
On 09.07.2011 00:36, Anish Kejariwal wrote:
My guess as to what happened:
-because the icecream parent table has zero records, the query optimizer
chooses the incorrect execution plan
-when I do select * from icecream, the optimizer now knows how many records
are really in the icecream table, by
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
