Re: [HACKERS] Custom compression methods (mac+lz4.h) - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: [HACKERS] Custom compression methods (mac+lz4.h)
Date
Msg-id CAFiTN-sm8Dpx3q92g5ohTdZu1_wKsw96-KiEMf3SoK8DhRPfWw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Custom compression methods (mac+lz4.h)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sun, Mar 21, 2021 at 7:03 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Also, I see some diffs in the
> indirect_toast test, which seems perhaps worthy of investigation.
> (The diffs look to be just row ordering, but why?)

I have investigated that,  actually in the below insert, after
compression the data size of (repeat('1234567890',50000)) is 1980
bytes with the lz4 whereas with pglz it is 5737 bytes.  So with lz4,
the compressed data are stored inline whereas with pglz those are
getting externalized.  Due to this for one of the update statements
followed by an insert, there was no space on the first page as data
are stored inline so the new tuple is stored on the next page and that
is what affecting the order.  I hope this makes sense.

INSERT INTO indtoasttest(descr, f1, f2) VALUES('one-toasted,one-null',
NULL, repeat('1234567890',50000));


-- 
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [PATCH] Identify LWLocks in tracepoints
Next
From: Amit Kapila
Date:
Subject: Re: Logical Replication vs. 2PC