Posts

Showing posts with the label toast

Character Types

Image
Introduction Overhead When you store a text string on disk, PostgreSQL cannot simply write those raw letters. If it only did that, upon reading the data back, Postgres would not know: How many bytes long is this string? Where does it end so it can read the next data column? Is this a short string, a long string, or compressed? Therefore, Postgres must spend a few extra bytes right at the beginning of the string to record this management information. This additional consumed capacity is called Overhead, which is the accompanying management cost. Header Structure PostgreSQL uses a common format named varlena (Variable-length array) to store all string types ( TEXT, VARCHAR, BYTEA, JSONB... ). This Overhead portion varies depending on the length of the data string: Very short strings (Under 127 bytes) Overhead: 1 byte . Mechanism: Postgres uses this first 1 byte ( 8 bits ) to store 7 bits for recording the actual length of the string, and 1 bit as a flag signaling that this is a s...

Boolean, Binary and UUID Types

Image
Introduction Next, we will explore Boolean, Binary and UUID Types as follows. Boolean Type BOOLEAN is a logical data type used to store true/false states, supporting three-valued logic such as TRUE , FALSE and NULL (unknown or missing data). Storage size is 1 byte . Commonly used to toggle features, activation status and soft delete flags ( is_deleted ). Postgres supports flexible INSERT syntax, so you do not necessarily have to write TRUE or FALSE . You can use equivalent keywords such as: TRUE state: 'true', 't', 'yes', 'y', '1', 1 FALSE state: 'false', 'f', 'no', 'n', '0', 0 Binary Data Types BYTEA (byte array) is used to store raw binary data without text processing, such as image files, PDF files, audio files, encryption certificates, RSA keys and more. Storage size is highly flexible. For short binary strings: Data size + 1 byte overhead. For long binary strings (over 2 KB): Uses compression ...

TOAST Storage Strategies

Image
Introduction As mentioned previously regarding storing data into HEAP, Postgres enforces a strict rule where a Row/Tuple must fit entirely within a single Page (8KB) and cannot overflow into another Page. The maximum size of a Row ranges from approximately 2KB to 8KB. If you intentionally insert a very long TEXT value or a file of several MBs into a row, an 8KB Page cannot accommodate such large data, prompting Postgres to trigger a mechanism called TOAST (The Oversized-Attribute Storage Technique). When you insert a data row whose size exceeds the allowed threshold (typically around 2KB), Postgres will not insert the entire row into the main HEAP. It executes the following three steps: Data compression: First, Postgres attempts to compress the oversized data to see if it fits within the 8KB Page. If successful, it is still inserted into the main HEAP. Chunking and moving to TOAST: If the data remains too large after compression, Postgres splits that 5MB data into multiple small chunks...