Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vQyiN-003QHq-2I for pgsql-hackers@arkaria.postgresql.org; Thu, 04 Dec 2025 02:05:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vQyiM-00HV10-2g for pgsql-hackers@arkaria.postgresql.org; Thu, 04 Dec 2025 02:05:03 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vQyiM-00HV0s-1K for pgsql-hackers@lists.postgresql.org; Thu, 04 Dec 2025 02:05:02 +0000 Received: from mail-ed1-x534.google.com ([2a00:1450:4864:20::534]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vQyiK-0031gD-0W for pgsql-hackers@lists.postgresql.org; Thu, 04 Dec 2025 02:05:01 +0000 Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-640b0639dabso569524a12.3 for ; Wed, 03 Dec 2025 18:05:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764813899; x=1765418699; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=9TpBjjNzmS49/5WFof6DAB73lXMQOerNutA0UATjRME=; b=Ihe+0L3Ln+nARJyxVHzObx/y9lMdDUgdXz1qiwEnxh6HLZsZkaXLGqNv+vg6vCOitU VI5WWQ7pbR7Kv92Mtc5mo+MsaRCYZVIJKycQHWsu23nFA4zKO7eYiWsr1vcurzEbp22d A1KIgISPvRXu28e1KAzx+xNNm7z//o3zFQrTsHYuhwnRmKUsIViYOttB1GU+fIa1rTeJ prGYXij2Zxg+DVqBFUZxPAwCyGcch9xMbn09RpX5phM+53Rdb6vZ3uGOpCXxyKruwSBK jNHa755tNxZmONpvk5+vGnTZ6GaH7CX6A9oBHArn3kbLtBAtTClOb16HyN/9JYzg2m76 4LWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764813899; x=1765418699; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=9TpBjjNzmS49/5WFof6DAB73lXMQOerNutA0UATjRME=; b=InFaCNs1B9Fh05rWRwdxPPmpobuIShjZcWEugR8Kf+jkjyI7fy7o/TIKJ3PsUwMDkg vz79VbKIHxwRt5rRmm68rgcuYUseXXXLQiM5by5GPTFTDhyeLHCoMw98ManDvwmKN7cX 7EizkzocMKJDQ3VtMmm5azo47LtvF9NwSn/tA5G0eAOjdm7Z5P8ycYUK8Og1IPB9Fexv tgb6z/5EIYUeglXAdIF4seOPCjgqqPJhBSXLwwynQ1ALXYWyPT3SVeV7L9/xJbtF4SXu UIPEvHewIYv0vjtaXaJpS8tfLOzPMXXRKnLDqb2ITbCTCbTtjL6RhThy84CCsB1Z1HMg 4jOw== X-Forwarded-Encrypted: i=1; AJvYcCUOHr0B8Xm6PTNvOT+Kjif8vENelrX/taD3APP5DUMYNlbPSRM2851dyq1FcFMxOP+SinazHXObtJtcgBK9@lists.postgresql.org X-Gm-Message-State: AOJu0YxcWvaj7vatVONKpimS1sJDE2wlcRBR6NVhW3DC7gWWAu8SRlwd gy37nFkEtXuDwFKq4IpxG6f38jnyLgK/FhplHD7NSk55Iys+M7f/Jbtzzbrn/JICuX++/ggOmax o7UylB0JbmQcZ9tQjblKFnm9EGPvEnTo= X-Gm-Gg: ASbGncuQ+DT+LvgC/kQthkFl6TOIvaUV4eSSdvJtV4m6bW5yqBttRDgdz3t7vywPUD2 uBJyof0kxdnQuUAJj5sbF1uTaF7M8fe+S5yS9bC9T0DrD7pn8mje1UmrjvD5DOa5DPAqKGMXj2L ZhgG0Cc726JXA5ieqAGQM7Ec7o8b93O7A/rUFCF2ax7N96rbMMzzk8ZURW1NBBEzPCHnTQBh9e5 YemgqPv6qy5DSze3CyOUaK6JHsC8Jf3g9wDawWELqv6dcAIhqLDbGnIuluL22eyh8/Akg== X-Google-Smtp-Source: AGHT+IFMvx9AWhYF4jLYwXDuKfI/AB+6WaTcZtvWxHCl5Sy6v8Btl1D833xldx9+0FCJVYyuAyb8H2CNiWT2v/Netsk= X-Received: by 2002:a05:6402:2106:b0:641:3d64:b120 with SMTP id 4fb4d7f45d1cf-6479c480adfmr3720297a12.18.1764813899299; Wed, 03 Dec 2025 18:04:59 -0800 (PST) MIME-Version: 1.0 References: <2bc58592-9d74-4af0-bdd1-1a88e8683f7c@iki.fi> <36531c0e-292c-409d-bbc7-a252cf6e910a@iki.fi> <54aa8f65-f0e4-4464-b543-e0399c1cab1e@iki.fi> <4a9dda70-0af7-41a4-9636-b168f2fc48ef@iki.fi> <46cc45e9-fddd-44bc-bcb3-96889aafd921@iki.fi> <6c298bc4-7029-4c1d-bf16-3e094842ce32@iki.fi> <9ee6324a-44fc-42fb-bf8e-7c3b53395588@iki.fi> <52227f05-51aa-40c4-8f83-9c79fff16175@iki.fi> In-Reply-To: From: wenhui qiu Date: Thu, 4 Dec 2025 10:04:46 +0800 X-Gm-Features: AWmQ_bkJrE6PXmQCypAIgSP2dXLYsNmewIpeizt2_DdlcCKE7qa7y0iewrTkp2o Message-ID: Subject: Re: POC: make mxidoff 64 bits To: Maxim Orlov Cc: Heikki Linnakangas , Alexander Korotkov , Alvaro Herrera , Postgres hackers , Ashutosh Bapat Content-Type: multipart/alternative; boundary="0000000000008ffedc064516c1c5" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000008ffedc064516c1c5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi > As a software developer, I definitely want to > implement compression an= d > save a few gigabytes. However, given my previous experience using > Postgres in real-world applications, reliability at the cost of several > gigabytes would not have caused me any trouble. Just saying. Agree +1, If this had been done twenty years ago, the cost might have been unacceptable. But with today=E2=80=99s hardware=E2=80=94especially disk ran= dom and sequential I/O performance improving by hundreds of thousands of times, and memory capacity increasing by several hundred times=E2=80=94it=E2=80=99s al= most unimaginable that we now have single 256-GB DIMMs. So this kind of overhead is negligible for modern hardware. Thanks On Wed, 3 Dec 2025 at 17:54, Maxim Orlov wrote: > The biggest problem with compression, in my opinion, is that losing > even one byte causes the loss of the entire compressed block in the > worst case scenario. After all, we still don't have checksums for the > SLRU's, which is a shame by itself. > > Again, I'm not against the idea of compression, but the risks need to > be considered. > > As a software developer, I definitely want to implement compression and > save a few gigabytes. However, given my previous experience using > Postgres in real-world applications, reliability at the cost of several > gigabytes would not have caused me any trouble. Just saying. > > -- > Best regards, > Maxim Orlov. > --0000000000008ffedc064516c1c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0
> As a software developer= , I definitely want to > =C2=A0implement compression and
>=C2=A0save a few gigabytes= . However, given my previous experience using
>=C2=A0Postgres in real-world application= s, reliability at the cost of several
>=C2=A0gigabytes would not have caused me any tro= uble. Just saying.
Agree +1,=C2=A0If this had been done twenty years ago, = the cost might have been unacceptable. But with today=E2=80=99s hardware=E2= =80=94especially disk random and sequential I/O performance improving by hu= ndreds of thousands of times, and memory capacity increasing by several hun= dred times=E2=80=94it=E2=80=99s almost unimaginable that we now have single= 256-GB DIMMs. So this kind of overhead is negligible for modern hardware.<= /span>

Thanks


On Wed, 3 Dec 2025 at 1= 7:54, Maxim Orlov <orlovmg@gmail.com> wrote:
The biggest problem with compression, in my opinion, is that losing
e= ven one byte causes the loss of the entire compressed block in the
worst= case scenario. After all, we still don't have checksums for the
SLR= U's, which is a shame by itself.

Again, I'm not against the = idea of compression, but the risks need to
be considered.

As a so= ftware developer, I definitely want to implement compression and
save a = few gigabytes. However, given my previous experience using
Postgres in r= eal-world applications, reliability at the cost of several
gigabytes wou= ld not have caused me any trouble. Just saying.
=
--
Best reg= ards,
Maxim Orlov.
--0000000000008ffedc064516c1c5--