From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Mike Sofen <msofen(at)runbox(dot)com>, 'postgres performance list' <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Postgres bulk insert/ETL performance on high speed servers - test results |
Date: | 2016-09-07 19:22:10 |
Message-ID: | d2676efc-d67a-4960-d07f-59d3db7588a2@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 9/4/16 7:34 AM, Mike Sofen wrote:
> You raise a good point. However, other disk activities involving large
> data (like backup/restore and pure large table copying), on both
> platforms, do not seem to support that notion. I did have both our IT
> department and Cisco turn on instrumentation for my last test, capturing
> all aspects of both tests on both platforms, and I’m hoping to see the
> results early next week and will reply again.
Something important to remember about Postgres is that it makes
virtually no efforts to optimize IO; it throws the entire problem in the
OSes lap. So differences in OS config or in IO *latency* can have a
massive impact on performance. Because of the sensitivity to IO latency,
you can also end up with a workload that only reports say 60% IO
utilization but is essentially IO bound (would be 100% IO utilization if
enough read-ahead was happening).
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532) mobile: 512-569-9461
From | Date | Subject | |
---|---|---|---|
Next Message | Mike Sofen | 2016-09-08 02:28:46 | Re: Postgres bulk insert/ETL performance on high speed servers - test results |
Previous Message | Mkrtchyan, Tigran | 2016-09-07 14:32:37 | debug_assertions is enabled in official 9.6rc1 build |