Re: [PERFORM] pg bouncer issue what does sv_used column means

Unsubscribe On Fri, Jun 12, 2015 at 8:57 PM, Sheena, Prabhjot < prabhjot.si...@classmates.com> wrote: > Guys we see spike in pg bouncer during the peak hours and that was > slowing down the application. We did bump up the connection limit and it is > helpful but now we again notice little spike

Re: [PERFORM] Postgresql in a Virtual Machine

orage (eg to reduce the load on the SAN). There is significant data copy involved, but as it's done in parallel with our live operations and doesn't cause noticeable performance drop it hasn't been an issue so far. On Tue, Nov 26, 2013 at 8:16 AM, David Lang wrote: > On Tu

Re: [PERFORM] Postgresql in a Virtual Machine

We have been running several Postgres databases on VMs for the last 9 months. The largest one currently has a few hundreds of millions of rows (~1.5T of data, ~100G of frequently queried data ) and performs at ~1000 tps. Most of our transactions are part of a 2PC, which effectively results to high

[PERFORM] Reseting statistics counters

If we reset the statistics counters using pg_stat_reset() will it affect the performance of the database? Eg are these the same statistics used by the planner? Thanks

Re: [PERFORM] pg_statio_all_tables columns

I do have a performance problem, and it is due to I/O bottleneck. We don't have pg_stat_statements installed, we will check it out. Thanks On Mon, Sep 30, 2013 at 8:44 PM, Jeff Janes wrote: > On Mon, Sep 30, 2013 at 5:45 AM, Xenofon Papadopoulos wrote: > >> I am trying

Re: [PERFORM] pg_statio_all_tables columns

Hello Giuseppe, do you actually mean I have a *poorly-cached *database? Should this ratio stay low even in the case of a write-heavy table? On Mon, Sep 30, 2013 at 5:40 PM, Giuseppe Broccolo < giuseppe.brocc...@2ndquadrant.it> wrote: > Hi Xenofon, > > Il 30/09/2013 14:45, Xenof

[PERFORM] pg_statio_all_tables columns

I am trying to understand the heap_blks_read and heap_blks_hit of pg_statio_all_tables in 9.2 Do the numbers refer only to SELECT, or they take INSERT into account? Would a heap_blks_read / ( heap_blks_read + heap_blks_hit ) ration of over 55% combined with a heap_blks_read value of over 50M indica

Re: [PERFORM] Distributed transactions and asynchronous commit

async commits in a DB without distributed transactions resulted to a huge decrease in I/O, here there was almost no effect. On Wed, Jul 17, 2013 at 2:21 PM, Vasilis Ventirozos wrote: > > > > On Wed, Jul 17, 2013 at 11:52 AM, Xenofon Papadopoulos > wrote: > >> Thank you for y

Re: [PERFORM] Distributed transactions and asynchronous commit

, Giuseppe Broccolo < giuseppe.brocc...@2ndquadrant.it> wrote: > 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, &g

[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