On 2 November 2014 05:33, Mike Wilson wrote:
> Any recommendations would be very helpful.
Try using ionice and renice to increase the priority of the WAL sender
process on the master. If it helps, you are lagging because not enough
resources are being used by the sender process (rather than the
On 28 October 2014 06:26, Huang, Suya wrote:
>Memory wanted: 3565580K bytes
This means "increase work_mem to this value".
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-performance mailing list (
Thanks for the confirmation Jerry.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Incredibly-slow-restore-times-after-9-0-9-2-upgrade-tp5824701p5825615.html
Sent from the PostgreSQL - performance mailing list archive at Nabble.com.
--
Sent via pgsql-performance mai
Not sure what is going on but other than upgrading to 9.3.4 from 9.2.4, i'm
seeing major slowness in basic queries and seeing a ton of the bind and
parse in my logs. These are standard lookups and should take micro seconds.
I'm logging all queries that take over a second and this seems to be
gettin
Tomas Vondra wrote
> On 29.10.2014 16:12, jmcdonagh wrote:
>> Hi Tomas- thank you for your thoughtful response!
>>
>>
>> Tomas Vondra wrote
>>> On 28.10.2014 21:55, jmcdonagh wrote:
Hi, we have a nightly job that restores current production data to
the development databases in a 'warm s
On Tue, Nov 4, 2014 at 9:01 AM, Tory M Blue wrote:
> Not sure what is going on but other than upgrading to 9.3.4 from 9.2.4,
> i'm seeing major slowness in basic queries and seeing a ton of the bind and
> parse in my logs. These are standard lookups and should take micro seconds.
> I'm logging al
Hi Tory,
On 4.11.2014 21:07, Tory M Blue wrote:
> Well after fighting this all day and dealing with a really sluggish db
> where even my slon processes were taking several seconds, I reduced my
> shared_buffers back to 2GB from 10GB and my work_mem from 7.5GB to 2GB.
> i actually undid all my chan
