On Fri, Jun 12, 2015 at 09:37:36PM +, Sheena, Prabhjot wrote:
> Here is some more information
>
> pool_mode | transaction
>
> We have transactional pooling and our application is set up in such a way
> that we have one query per transaction. We have set default pool size to
Please do not cross-post on the PostgreSQL lists. Pick the most
appropriate list to post to and just post there.
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-perform
Here is some more information
pool_mode | transaction
We have transactional pooling and our application is set up in such a way that
we have one query per transaction. We have set default pool size to 100.
This is output . As you guys can see active connection are 100 and 224 a
On Fri, Jun 12, 2015 at 4:52 PM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Fri, Jun 12, 2015 at 4:37 PM, Michael Nolan wrote:
>
>> The only thing I can come up that's happened since last night was that we
>> ran the nightly vacuum analyze on that database, but I did not change t
On 06/12/2015 01:37 PM, Michael Nolan wrote:
Last night I was doing some tuning on a database The longest query I
was running was taking around 160 seconds. I didn't see much change in
the running time for that query, even after restarting PG.
Today, with roughly the same system load (possibl
On Fri, Jun 12, 2015 at 4:37 PM, Michael Nolan wrote:
> The only thing I can come up that's happened since last night was that we
> ran the nightly vacuum analyze on that database, but I did not change the
> statistics target.
>
The answer to your question is no, parameters changes are worse w
Last night I was doing some tuning on a database The longest query I was
running was taking around 160 seconds. I didn't see much change in the
running time for that query, even after restarting PG.
Today, with roughly the same system load (possibly even a bit heavier
load), that query is runnin
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
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 in connection. And one thing that I notice that
is different is jump in sv_used value when I run command sh
On 10 June 2015 at 16:50, Tomas Vondra wrote:
>
>
> The problematic piece of the explain plan is this:
>
> -> Merge Join (cost=4384310.92..21202716.78 rows=6664163593
> width=390)"
>Output: a.ut, c.gt, b.go, b.gn, d.au"
>Merge Cond: ((c.ut)::text = (d.rart_id)
10 matches
Mail list logo