From: Jerry Sievers <gsievers19@comcast.net>
To: Rohan Kadekodi <kadekodirohan@gmail.com>
Cc: pgsql-admin@lists.postgresql.org
Subject: Re: Regarding postgreSQL performance on DRAM
References: 
 <CADb0YNk+jYXt6oC3vefFzOigmG8WOCkXmeAq5L8ABA4eMbypHA@mail.gmail.com>
Date: Wed, 20 Feb 2019 14:19:07 -0600
In-Reply-To: 
 <CADb0YNk+jYXt6oC3vefFzOigmG8WOCkXmeAq5L8ABA4eMbypHA@mail.gmail.com>
	(Rohan Kadekodi's message of "Wed, 20 Feb 2019 11:41:39 -0600")
Message-ID: <87va1exlfo.fsf@jsievers.enova.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Rohan Kadekodi <kadekodirohan@gmail.com> writes:

> Hello,
>
> I am a researcher in the Storage and Systems Lab at UT Austin. I am
> working on analyzing the performance of PostgreSQL on Persistent
> Memory. To be more specific, I am trying to analyze the performance
> of PostgreSQL-10.5 on a ramdisk device mounted with the ext4 file
> system.
>
> My workload is simple. I=C2=A0 insert 1 million rows into a table with 100
> columns, where each column is 256 bytes in length, and every 10
> inserts are batched into a transaction.=C2=A0

Your test workload qualifies for TOASTing due to the $unrealistically
long physical tuple size.

Thusly, by default compression is also in-scope and the heavy CPU impact
showing up in your performance metrics.

Revising the test to substantially reduce or eliminate the burden of
toasting and especially compression should help in the I/O measurements.

HTH

>
> On running strace on all the PostgreSQL processes spawned by the
> server, I am observing that the total time taken in system calls is
> less than 5% of the total time it takes to do the 1 million inserts.
> I changed the configuration file to make PostgreSQL as synchronous as
> possible, and even then the time spent in system calls is very low.=C2=A0
>
> When I run the perf tool to check where the majority time is being
> spent, I see that there is a function called pglz_compress() where a
> lot of time is getting spent and also there is a function called
> heap_compute_data_size() where there is significant time spent.=C2=A0
>
> Could I know why so much time is being spent in user space, and how I
> can make PostgreSQL more I/O bound than it is now?
>
> Thanks!
> - Rohan
>
>

--=20
Jerry Sievers
Postgres DBA/Development Consulting
e: postgres.consulting@comcast.net