Frank Lanitz wrote:
> Am 12.02.2012 11:48, schrieb Ofer Israeli:
>> Frank Lanitz wrote:
Am 07.02.2012 18:40, schrieb Ofer Israeli:
>> Table 1: 46 columns 23 indexes on fields of the following
>> types: INTEGER - 7 TIMESTAMP - 2 VARCHAR - 12 UUID - 2
>>
>> 23 columns 12 indexes
Am 12.02.2012 11:48, schrieb Ofer Israeli:
> Frank Lanitz wrote:
>>> Am 07.02.2012 18:40, schrieb Ofer Israeli:
> Table 1: 46 columns 23 indexes on fields of the following
> types: INTEGER - 7 TIMESTAMP - 2 VARCHAR - 12 UUID - 2
>
> 23 columns 12 indexes on fields of the following
Frank Lanitz wrote:
> Am 07.02.2012 18:40, schrieb Ofer Israeli:
>> Table 1:
>> 46 columns
>> 23 indexes on fields of the following types:
>> INTEGER - 7
>> TIMESTAMP - 2
>> VARCHAR - 12
>> UUID - 2
>>
>> 23 columns
>> 12 indexes on fields of the following types:
>> INTEGER - 3
>> TIMESTAMP - 1
>>
Am 07.02.2012 18:40, schrieb Ofer Israeli:
> Table 1:
> 46 columns
> 23 indexes on fields of the following types:
> INTEGER - 7
> TIMESTAMP - 2
> VARCHAR - 12
> UUID - 2
>
> 23 columns
> 12 indexes on fields of the following types:
> INTEGER - 3
> TIMESTAMP - 1
> VARCHAR - 6
> UUID - 2
Are you re
On Wed, Feb 8, 2012 at 20:22, Ofer Israeli wrote:
> Andy Colson wrote:
> > Oh, I knew I'd seen index usage stats someplace.
> >
> > give this a run:
> >
> > select * from pg_stat_user_indexes where relname = 'SuperBigTable';
> >
> > http://www.postgresql.org/docs/current/static/monitoring-stats.h
Andy Colson wrote:
> Oh, I knew I'd seen index usage stats someplace.
>
> give this a run:
>
> select * from pg_stat_user_indexes where relname = 'SuperBigTable';
>
> http://www.postgresql.org/docs/current/static/monitoring-stats.html
>
> -Andy
>
> Scanned by Check Point Total Security Gateway
Claudio Freire wrote:
> On Tue, Feb 7, 2012 at 4:12 PM, Ofer Israeli
> wrote:
>> Something specific that you refer to in autovacuum's non-perfection,
>> that is, what types of issues are you aware of?
>
> I refer to its criteria for when to perform vacuum/analyze.
> Especially analyze. It usual
Oh, I knew I'd seen index usage stats someplace.
give this a run:
select * from pg_stat_user_indexes where relname = 'SuperBigTable';
http://www.postgresql.org/docs/current/static/monitoring-stats.html
-Andy
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make
Andy Colson wrote:
> Wow, so out of 46 columns, half of them have indexes? That's a
> lot. I'd bet you could drop a bunch of them. You should review
> them and see if they are actually helping you. You already found
> out that maintain all those indexes is painful. If they are not
> speedin
-Original Message-
From: Andy Colson [mailto:a...@squeakycode.net]
Sent: Tuesday, February 07, 2012 4:47 PM
To: Ofer Israeli
Cc: pgsql-performance@postgresql.org; Olga Vingurt; Netta Kabala
Subject: Re: [PERFORM] Inserts or Updates
On 2/7/2012 4:18 AM, Ofer Israeli wrote:
Hi all,
We
On Tue, Feb 7, 2012 at 4:12 PM, Ofer Israeli wrote:
> Something specific that you refer to in autovacuum's non-perfection, that is,
> what types of issues are you aware of?
I refer to its criteria for when to perform vacuum/analyze. Especially
analyze. It usually fails to detect the requirement
>> You mean running a VACUUM statement manually? I would basically try to
>> avoid such a situation as the way I see it, the database should be
>> configured in such a manner that it will be able to handle the load at
>> any given moment and so I wouldn't want to manually intervene here. If
>>
On Tue, Feb 7, 2012 at 2:43 PM, Ofer Israeli wrote:
> You mean running a VACUUM statement manually? I would basically try to avoid
> such a situation as the way I see it, the database should be configured in
> such a manner that it will be able to handle the load at any given moment and
> so I
erformance@postgresql.org
Subject: Re: [PERFORM] Inserts or Updates
On Tue, Feb 7, 2012 at 2:27 PM, Ofer Israeli wrote:
> Thanks Kevin for the ideas. Now that you have corrected our misconception
> regarding the autovacuum not handling index bloating, we are looking into
> running autovacuum freque
, February 07, 2012 4:47 PM
To: Ofer Israeli
Cc: pgsql-performance@postgresql.org; Olga Vingurt; Netta Kabala
Subject: Re: [PERFORM] Inserts or Updates
On 2/7/2012 4:18 AM, Ofer Israeli wrote:
> Hi all,
>
> We are currently "stuck" with a performance bottleneck in our server
&g
On Tue, Feb 7, 2012 at 2:27 PM, Ofer Israeli wrote:
> Thanks Kevin for the ideas. Now that you have corrected our misconception
> regarding the autovacuum not handling index bloating, we are looking into
> running autovacuum frequently enough to make sure we don't have significant
> increase i
Olga Vingurt
Subject: Re: [PERFORM] Inserts or Updates
Ofer Israeli wrote:
> Our system has a couple of tables that hold client generated
> information. The clients communicate every minute with the server
> and thus we perform an update on these two tables every minute. We
> are t
On 2/7/2012 4:18 AM, Ofer Israeli wrote:
Hi all,
We are currently “stuck” with a performance bottleneck in our server
using PG and we are thinking of two potential solutions which I would be
happy to hear your opinion about.
Our system has a couple of tables that hold client generated
informati
Ofer Israeli wrote:
> Our system has a couple of tables that hold client generated
> information. The clients communicate every minute with the server
> and thus we perform an update on these two tables every minute. We
> are talking about ~50K clients (and therefore records).
>
> These constan
Hi all,
We are currently "stuck" with a performance bottleneck in our server using PG
and we are thinking of two potential solutions which I would be happy to hear
your opinion about.
Our system has a couple of tables that hold client generated information. The
clients communicate every minut
20 matches
Mail list logo
