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
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
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 spare' database so that if th
jmcdonagh writes:
> I just had a thought- I know some of these tables are in need of a vacuuming.
> Could it be that the dump is dumping a bunch of garbage that the restore has
> to sift through on the restore? I don't know enough details to know if this
> is a dumb thought or not.
No. However
I just had a thought- I know some of these tables are in need of a vacuuming.
Could it be that the dump is dumping a bunch of garbage that the restore has
to sift through on the restore? I don't know enough details to know if this
is a dumb thought or not.
The restore to RDS took roughly the same
Hi Jason, oddly enough the setting on or off does not affect this particular
issue. As a rule I generally enable this option on my instances that support
it. I recently tried upping the nodes to the latest generation (m3) to try
and rectify/improve this issue. Unfortunately right now m3 won't work
Is the instance ebs-optimized? I am wondering if its a configuration on the
instance not postgres or ebs.
On Wed, Oct 29, 2014 at 10:12 AM, 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 n
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 spare' database so that if the
>> developers need fresh data, it's ready durin
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 spare' database so that if the
> developers need fresh data, it's ready during the day. When we moved
> from 9.0 to 9.2 suddenly the restores began to ta
Hi, we have a nightly job that restores current production data to the
development databases in a 'warm spare' database so that if the developers
need fresh data, it's ready during the day. When we moved from 9.0 to 9.2
suddenly the restores began to take from a few hours to more like 15 hours
or s
10 matches
Mail list logo