On Tue, Feb 7, 2012 at 3:11 PM, Igor Neyman wrote:
> From: Gudmundur Johannesson [mailto:gudmundur.johannes...@gmail.com]
> Sent: Thursday, February 02, 2012 11:42 AM
> To: Merlin Moncure
> Cc: pgsql-performance@postgresql.org
> Subject: Re: Index with all necessary columns - Postgres vs MSSQL
>
PostgreSQL 9.1.2 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.1.2
20080704 (Red Hat 4.1.2-51), 64-bit
Dedicated DB server
4GB ram
Shared_Buffers = 1 GB
Effective_cache_size = 3GB
Work_mem = 32GB
Analyze done
Queries ran multiple times, same differences/results
Default Statistics = 1
On 02/04/2012 06:25 PM, Tomas Vondra wrote:
What should I do to see the effect of direct I/O?
Test something other than a mainstream Linux filesystem. The two times
I've either measured an improvement myself for direct I/O were a)
Veritas VxFS on Linux, which has some documented acceleration
Per the thread from last month, I've updated the default
random_page_cost on Heroku Postgres to reduce the expected cost of a
random_page on all new databases.
Thanks to everyone who helped come to this conclusion!
Peter
--
Peter van Hardenberg
San Francisco, California
"Everything was beautifu
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 are
On Tue, Feb 7, 2012 at 11:59 AM, Gudmundur Johannesson
wrote:
> On Tue, Feb 7, 2012 at 3:11 PM, Igor Neyman wrote:
>>
>> From: Gudmundur Johannesson [mailto:gudmundur.johannes...@gmail.com]
>> Sent: Thursday, February 02, 2012 11:42 AM
>> To: Merlin Moncure
>> Cc: pgsql-performance@postgresql.org
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
Hi Claudio,
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 y
Hi Andy,
The two tables I am referring to have the following specs:
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
All indexes
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
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 in table size or index size. We intend to keep our transactio
From: Gudmundur Johannesson [mailto:gudmundur.johannes...@gmail.com]
Sent: Thursday, February 02, 2012 11:42 AM
To: Merlin Moncure
Cc: pgsql-performance@postgresql.org
Subject: Re: Index with all necessary columns - Postgres vs MSSQL
Hi,
I want to start by thanking you guys for a quick response
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
19 matches
Mail list logo
