Re: POC: make mxidoff 64 bits

From: Maxim Orlov <orlovmg(at)gmail(dot)com>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, wenhui qiu <qiuwenhuifx(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
Subject: Re: POC: make mxidoff 64 bits
Date: 2025-12-03 09:54:23
Message-ID: CACG=ezY-uzrQvUbm4_txT6hR4r78cgLoXGpT61+OXGodLw=qZA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2025-12-03 09:57:32 Re: Serverside SNI support in libpq
Previous Message vignesh C 2025-12-03 09:50:31 Fix START_REPLICATION failure with publication names containing backslashes