Hello,
I am happy to hear that you have received all the help.
Please feel free to contact us for professional assistance any time you may
need in the future.
Most Welcome!
Regards,
Mark Avinash Hogg
Director of Business Development
2ndQuadrant
+1(647) 770 9821 Cell
www.2ndquadrant.com
On Wed, Jan 9, 2019 at 3:52 PM Haroldo Kerry wrote:
> @Justin @Merlin @ Jeff,
> Thanks so much for your time and insights, they improved our understanding
> of the underpinnings of PostgreSQL and allowed us to deal the issues we
> were facing.
> Using parallel query on our PG 9.6 improved a lot
@Justin @Merlin @ Jeff,
Thanks so much for your time and insights, they improved our understanding
of the underpinnings of PostgreSQL and allowed us to deal the issues we
were facing.
Using parallel query on our PG 9.6 improved a lot the query performance -
it turns out that a lot of our real
>
>
> *Performance issue:*
>
> I’m trying to figure out if PostgreSQL (PG) has some inherent limit on
> IOPS per connection.
>
> Running pgbench with multiple clients (-c 30) we are able to see 20K+ IOPS
> , which is what we expect. But, if we use just one client, we get 1200
> IOPS, avg disk
Justin,
Thanks for the quick response, I'll check it out.
Happy holidays,
Haroldo Kerry
On Thu, Dec 27, 2018 at 2:55 PM Justin Pryzby wrote:
> On Thu, Dec 27, 2018 at 02:44:55PM -0200, Haroldo Kerry wrote:
> > PostgreSQL 9.6.10 on x86_64-pc-linux-gnu (Debian 9.6.10-1.pgdg80+1),
>
> > Connected
On Thu, Dec 27, 2018 at 02:44:55PM -0200, Haroldo Kerry wrote:
> PostgreSQL 9.6.10 on x86_64-pc-linux-gnu (Debian 9.6.10-1.pgdg80+1),
> Connected to SAN: Dell Compellent SC2020, with 7 x Samsung PM1633 SSDs
> https://www.samsung.com/us/labs/pdfs/collateral/pm1633-prodoverview-2015.pdf,
>