Performance issues with composite types (partitioned table)

Hello,

We are having performance issues with a table partitioned by date, using composite type columns.
I have attached the table definition, full reproducible of the issue and execution plans to this email.

Ultimately, we want to sum certain fields contained in those composite types,
using a simple status filter across one month (31 partition) and group by date.
But, we fail to get a satisfactory performance even on a single partition.

I have tried multiple indexing options, but none work for us, as I will explain.
I will refer to these indexes as: ix1, ix2, ix3, ix4, ix5, ix6 and for the second part ix7.
ix1-ix6 are defined in the attached repro.sql file and the performance of the query with each of them is shown in exec_plans file.
ix7 is defined in the repro_part_vs_parent.sql and performance of relevant queries in exec_plans_part_vs_parent file.

This is the query targeting single partition:

SELECT
SUM(COALESCE((col1).a + (col1).b + (col1).c + (col1).d, 0)) AS val1,
SUM(COALESCE((col2).y, 0)) AS val2
FROM
public."mytable:2020-12-09" --single partition of public.mytable
WHERE status IN (1,2,3,4);

We get the best performance using ix2, while I would expect to get better performance using ix3, and perhaps ix5. 

Questions:
1. Why cannot Postgres plan for index-only scan with ix3?
2. Why is the query cost so high when using ix3?
3. Is it possible to define an index such as ix3, that is, with a drastically reduced size and listing only expressions we project?
4. Are there any other indexing or query rewrite options that are worth trying here?
5. Judging by execution time, it seems that Postgres can leverage defined expressions in ix2, so why not in ix3? Why must it fetch col1 and col2 from the table when I force ix3 usage?
6. As ix3 is only 53MB in size (see repro.sql) as opposed to ix1 and ix2 which are 266MB and 280MB respectively, I would expect Postgres to use it instead?


In addition to this, please look at the attached repro_part_vs_parent.sql file and its related execution plans file.
There, I tried running a similar query on a partitioned table targeting a single partition, and afterwards on the partition itself.
The results confuse me. I would expect to get similar performance in both situations, but the query runs much slower through the parent table.
By looking at the output of the seq scan node (parent query), it seems that running the query on the parent table prepends partition name as an alias to projected columns.
Does that make Postgres unable to recognize the expression in the index, or is there something else happening here?