Re: [HACKERS] Custom compression methods

On Sat, Feb 20, 2021 at 11:04 AM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> On Sat, Feb 20, 2021 at 2:51 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> >
> > On Fri, Feb 19, 2021 at 11:12 AM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> > I think that these performance tests aren't really exercising the
> > expanded-record stuff, just the ExecEvalRow changes. We need to test
> > that test case, and I tend to suspect there's going to be a measurable
> > regression.
>
> I will do testing around this area.

I have done testing for the expanded-record. Basically I have noticed
there is no performance regression when there are no
compressed/external fields. But there is a huge regression when there
are compressed data.

Test setup:
----------------
create table foo (a int, b text, c text);
create table bar (f foo);

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

create or replace function test() returns void AS
$$
begin
for i in 1..100000 loop
insert into bar select make_foo();
end loop;
end;
$$ language 'plpgsql';

Testcase: select test(); (every time truncate bar before executing this query)

Case1: No compress/no external
insert into foo select 1, repeat('1234567890', 10), repeat('1234567890', 10);

execution time for "select test()"
Head: 2536.420 ms
patch: 2688.565 ms

Case2: Only compress
insert into foo select 1, repeat('1234567890', 500), repeat('1234567890', 10);

execution time for "select test()"
head: 2545.944 ms
Patch: 9375.524 ms

Case2: compress + external
Alter table foo alter column c set storage external;
insert into foo select 1, repeat('1234567890', 500), repeat('1234567890', 500);

execution time for "select test()"
Head: 10265.052 ms
Patch: 15469.902 ms

Summary:
In this particular path we are only processing the already deformed
tuple that is the reason we are not seeing regression with the
non-compressed data. But with compressed data we have to give extra
cost for the decompression and that is why there is regression. But
IMHO with this we are getting one benefit is that now we will not have
individual compressed data inside composite type so next time when we
will have to select from those composite type then we will have to do
less decompression with patch compared to the head so we might gain
there. I will try to come up with the complete test case where we
will do selection after inserting into the composite type and compare
the performance.

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