From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Kellerer <spam_eater@gmx.net>
cc: pgsql-admin@lists.postgresql.org
Subject: Re: Regarding postgreSQL performance on DRAM
In-reply-to: <f37b7ea7-966d-d54a-bf8d-a1c7229e5f8a@gmx.net>
References: 
 <CADb0YNk+jYXt6oC3vefFzOigmG8WOCkXmeAq5L8ABA4eMbypHA@mail.gmail.com>
 <87va1exlfo.fsf@jsievers.enova.com>
 <f37b7ea7-966d-d54a-bf8d-a1c7229e5f8a@gmx.net>
Comments: In-reply-to Thomas Kellerer <spam_eater@gmx.net>
	message dated "Wed, 20 Feb 2019 21:42:22 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <29250.1550696663.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 20 Feb 2019 16:04:23 -0500
Message-ID: <29251.1550696663@sss.pgh.pa.us>
Precedence: bulk

Thomas Kellerer <spam_eater@gmx.net> writes:
> Jerry Sievers schrieb am 20.02.2019 um 21:19:
>>> My workload is simple. I 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.

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

> Hmm. I though TOAST is only applied to single values, not the entire tup=
le (row)?
> As each column is substantially shorter than the TOAST threshold, I woul=
d not expect toasting to kick in here.

Well, the entire tuple would be 25600 bytes plus some overhead, which
cannot fit on a Postgres page (8K, unless the OP changed compile options
without mentioning it).  So something has to be done to make it fit, and
that something is going to be toasting any fields that can be toasted.

=46rom memory, our threshold for trying to make tuples narrower is only
a quarter-page anyway, so that the toaster will be trying to get this
down to 2K if it can.  That's certainly going to involve compressing
every field, and I wouldn't be surprised if a lot of them get shoved
out-of-line too.

The OP might care to read

https://www.postgresql.org/docs/current/storage-toast.html

			regards, tom lane