Re: [PERFORM] PostgreSQL settings for running on an SSD drive

On 6/20/13 4:32 PM, Josh Berkus wrote: First, cc'ing Greg Smith to see if he can address this with the Fusion folks so that they stop giving out a bad guide. I'm working on a completely replacement of that guide, one that actually gives out a full set of advice. Right now I'm between their pr

[PERFORM] Re: bgwriter autotuning might be unnecessarily penalizing bursty workloads

On 7/17/13 6:46 PM, Josh Berkus wrote: The key metric I'm looking at is that the bgwriter only took care of 0.3% of buffers. There look to be a good number of buffers on this server that are only being written at checkpoint time. The background writer will only deal with buffers when their u

[PERFORM] bgwriter autotuning might be unnecessarily penalizing bursty workloads

Greg, All: So, I've been running some stats over some customer workloads who are having issues with checkpoint spikes, and I'm finding that the bgwriter is almost entirely ineffective for them: pct_checkpoints_req | 33.0 avg_frequency_min | 2.30 avg_write_time_s| 112.17 avg_sync

Re: [PERFORM] Seq Scan vs Index on Identical Tables in Two Different Databases

I guess not. I usually vacuum with the analyze option box checked; I must have missed that this cycle. It looks much better now. Thanks! From: bricklen [mailto:brick...@gmail.com] Sent: Wednesday, July 17, 2013 4:12 PM To: Ellen Rothman Cc: pgsql-performance@postgresql.org

Re: [PERFORM] Seq Scan vs Index on Identical Tables in Two Different Databases

On Wed, Jul 17, 2013 at 07:50:06PM +, Ellen Rothman wrote: - I have the same table definition in two different databases on the same computer. When I explain a simple query in both of them, one database uses a sequence scan and the other uses an index scan. If I try to run the Seq Scan vers

[PERFORM] Re: Seq Scan vs Index on Identical Tables in Two Different Databases

Ellen Rothman wrote > I have the same table definition in two different databases on the same > computer. You really should prove this to us by running schema commands on the table and providing results. Also, version information has not been provided and you do not state whether the databases a

Re: [PERFORM] Seq Scan vs Index on Identical Tables in Two Different Databases

On Wed, Jul 17, 2013 at 12:50 PM, Ellen Rothman wrote: > I have the same table definition in two different databases on the same > computer. When I explain a simple query in both of them, one database uses > a sequence scan and the other uses an index scan. If I try to run the Seq > Scan version

[PERFORM] Seq Scan vs Index on Identical Tables in Two Different Databases

I have the same table definition in two different databases on the same computer. When I explain a simple query in both of them, one database uses a sequence scan and the other uses an index scan. If I try to run the Seq Scan version without the where clause restricting the value of uniqueid, i

Re: [PERFORM] Distributed transactions and asynchronous commit

wal_buffers: 32M effective_io_concurrency: 4 There is no bloat. Note that we are using Postgres inside a VM, there is a VMFS layer on top of the LUNs which might affect the performance. That said, we're still wondering if this much I/O is normal and if we can somehow reduce it. Enabling async comm

Re: [PERFORM] Distributed transactions and asynchronous commit

On Wed, Jul 17, 2013 at 12:21 PM, Vasilis Ventirozos wrote: > > > > On Wed, Jul 17, 2013 at 11:52 AM, Xenofon Papadopoulos > wrote: > >> Thank you for your replies so far. >> The DB in question is Postgres+ 9.2 running inside a VM with the >> following specs: >> >> 16 CPUs (dedicated to the VM)

Re: [PERFORM] Distributed transactions and asynchronous commit

On Wed, Jul 17, 2013 at 11:52 AM, Xenofon Papadopoulos wrote: > Thank you for your replies so far. > The DB in question is Postgres+ 9.2 running inside a VM with the following > specs: > > 16 CPUs (dedicated to the VM) > 60G RAM > RAID-10 storage on a SAN for pgdata and pgarchieves, using differen

Re: [PERFORM] Distributed transactions and asynchronous commit

Il 17/07/2013 12:52, Xenofon Papadopoulos ha scritto: Thank you for your replies so far. The DB in question is Postgres+ 9.2 running inside a VM with the following specs: 16 CPUs (dedicated to the VM) 60G RAM RAID-10 storage on a SAN for pgdata and pgarchieves, using different LUNs for each.

Re: [PERFORM] Distributed transactions and asynchronous commit

Thank you for your replies so far. The DB in question is Postgres+ 9.2 running inside a VM with the following specs: 16 CPUs (dedicated to the VM) 60G RAM RAID-10 storage on a SAN for pgdata and pgarchieves, using different LUNs for each. We have 3 kind of queries: - The vast majority of the que

Re: [PERFORM] Distributed transactions and asynchronous commit

Hi, Il 17/07/2013 09:18, Xenofon Papadopoulos ha scritto: In the asynchronous commit documentation, it says: /The commands supporting two-phase commit, such as PREPARE TRANSACTION, are also always synchronous / Does this mean that all queries that are part of a distributed transaction are s

Re: [PERFORM] Distributed transactions and asynchronous commit

> > In the asynchronous commit documentation, it says: > > *The commands supporting two-phase commit, such as PREPARE TRANSACTION, > are also always synchronous > * > > Does this mean that all queries that are part of a distributed transaction > are synchronous? > Yep > In our databases we have

Re: [PERFORM] Trying to eliminate union and sort

I'd try to check why discounts are different. Join with 'or' should work. Build (one query) except all (another query) and check some rows from result. 13 лип. 2013 01:28, "Brian Fehrle" напис. > On 07/11/2013 06:46 PM, Josh Berkus wrote: > >> Brian, >> >> 3. I'm trying to eliminate the union,

[PERFORM] Distributed transactions and asynchronous commit

In the asynchronous commit documentation, it says: *The commands supporting two-phase commit, such as PREPARE TRANSACTION, are also always synchronous * Does this mean that all queries that are part of a distributed transaction are synchronous? In our databases we have extremely high disk I/O, I