Horton

Re: [HACKERS] Custom compression methods

Dilip Kumar <dilipbalaut@gmail.com>

View thread View on postgr.es
From: Dilip Kumar <dilipbalaut@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Justin Pryzby <pryzby@telsasoft.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, Alexander Korotkov <a.korotkov@postgrespro.ru>, David Steele <david@pgmasters.net>, Ildus Kurbangaliev <i.kurbangaliev@gmail.com>, Dmitry Dolgov <9erthalion6@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-02-20T09:15:09Z
Lists: pgsql-hackers 
On Sat, Feb 20, 2021 at 11:04 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:

> Even after the above case, we might say it is still not a problem for
> this patch because even though t2 doesn't have a direct relationship
> with lz4 but it has an indirect relationship with lz4 via t1.  So I
> think this particular case which I showed might not be a problem even
> for the custom compression method.  However, I agree that the
> decompressing to survive COMMIT/ROLLBACK might be a problem for custom
> compression methods but not for the built-in method.   So I agree with
> the conclusion that even if we don't make any changes to the
> "expandedrecord.c", it won't be a problem for the built-in methods.

I think I was wrong here, consider below scenario (Robert had sent
this test to me(offlist) for showing some other example, which I have
modified a bit to prove another point)

create table foo (a int, b text);
create table foo1 (a int, b text compression lz4);
insert into foo1 select 1, repeat('a', 3000);

create or replace function make_foo() returns foo as $$declare x foo;
begin
x.a = 1;
select b into x.b from foo1;
return x;
end$$ language plpgsql;

create table bar (f foo);
insert into bar select make_foo();
SELECT pg_column_compression((bar.f).b) FROM bar;
 pg_column_compression
-----------------------
 lz4
(1 row)

So basically, now table bar doesn't have any relation with foo1 and it
is still the row with compression method lz4.  This issue is resolved
with my changes in
(v25_0001_Disallow_compressed_data_inside_container_types, in
expandedrecord.c).  So the point is that for the built-in method also
we need changes related to expandedrecord at least the changes I made
where tuple are actually formed for inserting into the target.

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

Commits

  1. docs: Update TOAST storage docs for configurable compression.

  2. Further tweaking of pg_dump's handling of default_toast_compression.

  3. Fix interaction of TOAST compression with expression indexes.

  4. Tidy up more loose ends related to configurable TOAST compression.

  5. Short-circuit slice requests that are for more than the object's size.

  6. Mostly-cosmetic adjustments of TOAST-related macros.

  7. Remove useless configure probe for <lz4/lz4.h>.

  8. Error on invalid TOAST compression in CREATE or ALTER TABLE.

  9. docs: Fix omissions related to configurable TOAST compression.

  10. More code cleanup for configurable TOAST compression.

  11. Bring configure support for LZ4 up to snuff.

  12. Make compression.sql regression test independent of default.

  13. Use valid compression method in brin_form_tuple

  14. Fix up pg_dump's handling of per-attribute compression options.

  15. Allow configurable LZ4 TOAST compression.

  16. Fix inconsistencies in the code

  17. Mostly-cosmetic improvements in memory chunk header alignment coding.

  18. Allow numeric to use a more compact, 2-byte header in many cases.