public inbox for [email protected]
help / color / mirror / Atom feedFrom: wenhui qiu <[email protected]>
To: Maxim Orlov <[email protected]>
Cc: Heikki Linnakangas <[email protected]>
Cc: Alexander Korotkov <[email protected]>
Cc: Alvaro Herrera <[email protected]>
Cc: Postgres hackers <[email protected]>
Cc: Ashutosh Bapat <[email protected]>
Subject: Re: POC: make mxidoff 64 bits
Date: Thu, 4 Dec 2025 10:04:46 +0800
Message-ID: <CAGjGUALW4f=r-NJyXqaSbw-HR+=v60Un=89fEttQOwm5Vy0sgQ@mail.gmail.com> (raw)
In-Reply-To: <CACG=ezY-uzrQvUbm4_txT6hR4r78cgLoXGpT61+OXGodLw=qZA@mail.gmail.com>
References: <CACG=ezaWg7_nt-8ey4aKv2w9LcuLthHknwCawmBgEeTnJrJTcw@mail.gmail.com>
<[email protected]>
<CACG=ezZwdvsijzuXE3hex3xHcoz75EQYBXRTsQJVwbo5J5sS3g@mail.gmail.com>
<CACG=ezbs912S58=uR17b4w8uuWv1=OcCRaTW_OWdFm4+tXZA6w@mail.gmail.com>
<CAGjGUA+BfcWyccNN4=tHsW_E-koRxbg8h8ut6hjvPsHMgmek6w@mail.gmail.com>
<CACG=ezYbYO_KHWdeDedbDcY0tOS0JfaqBxG3=bG5+DdsDK4MpQ@mail.gmail.com>
<CACG=ezYpZRPwoRCz_h3Qerd3XJNdpTHCpwGbZphNdy26tA4_qQ@mail.gmail.com>
<[email protected]>
<[email protected]>
<CACG=ezYUJSvnuxntkURNWo_1vZ+AtmcQfqd_h6WgDzGaudfw+Q@mail.gmail.com>
<[email protected]>
<[email protected]>
<CAExHW5tUEkiQrvm9hgccjKUNkWBnJ5_HDUrAwiHBTxu+Vuj29Q@mail.gmail.com>
<[email protected]>
<[email protected]>
<CAPpHfdsMd9TQ8ZbMnStMfFvBoBMwBCSC+8zcOYY9VDMYQzUYyQ@mail.gmail.com>
<[email protected]>
<CACG=ezY-uzrQvUbm4_txT6hR4r78cgLoXGpT61+OXGodLw=qZA@mail.gmail.com>
Hi
> 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.
Agree +1, If this had been done twenty years ago, the cost might have been
unacceptable. But with today’s hardware—especially disk random and
sequential I/O performance improving by hundreds of thousands of times, and
memory capacity increasing by several hundred times—it’s almost
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 <[email protected]> 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.
>
view thread (79+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: POC: make mxidoff 64 bits
In-Reply-To: <CAGjGUALW4f=r-NJyXqaSbw-HR+=v60Un=89fEttQOwm5Vy0sgQ@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox