Re: Does TOAST really compress the complete row?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Kellerer <shammat(at)gmx(dot)net>
Cc: Postgres General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Does TOAST really compress the complete row?
Date: 2020-07-02 22:15:50
Message-ID: 890934.1593728150@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Thomas Kellerer <shammat(at)gmx(dot)net> writes:
> I am confused about one claim in this blog post: https://www.2ndquadrant.com/en/blog/oracle-to-postgresql-binary-objects

>> All columns that come after data > 2000 bytes participate in The
>> Large Attribute Strorage Technique (TOAST). This storage is for the
>> row, not the column. Your id column comes as the last column in the
>> table? Whoopsie, your primary key just got shoved into blob storage

> I always was under the impression that TOASTing only happens on column level, not on row level.

You're right, and the quoted text is wrong. Not only does TOAST compress
fields not whole rows, but it selectively targets wider fields first.
If your pkey is getting toasted, you should likely rethink your choice
of pkey. (Or, possibly, you just have so many fields there's no choice
but to compress all of them. Then it might be time for a table redesign.)

The decision-making about this is concentrated in
heap_toast_insert_or_update, which can be seen here:

https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/access/heap/heaptoast.c

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2020-07-02 22:25:38 Re: Different results from identical matviews
Previous Message Anders Steinlein 2020-07-02 22:05:27 Re: Different results from identical matviews