Nikhil

this is being abandoned since @pmwkaa has a different approach to solve this in https://github.com/timescale/timescaledb/pull/4771

@ainz-95 is the current behavior causing any specific issues for you? Does @hartmutbehrens' work around work for you? As @dtwright pointed out, depending on the use case, it might actually...

@alx696 did you get a chance to try out the above pieces of sql?

@davidkohn88 it seems to be working just fine for me with latest TS sources and latest data from our website. I did invoke `ANALYZE` manually on the table before running...

@Tomasz365 this is expected behavior in Multinode. We will use `REPEATABLE READ` transaction isolation level by default for connections made for the INSERT into the datanodes from the access node....

PR #4771 submitted to solve this

The following test case now works. ``` CREATE TYPE mytype AS (low int, high int); -- on AN and and on all DNs CREATE TABLE arrtable (time timestamptz, val mytype[]);...

@semabtariq1 can you please confirm that the sizes are the same after using the exact same index definition? Please close this issue in that case.

@mmpatil your timescaledb version 2.5.0 is kinda old. Please update it to 2.14.x when you get the chance.

> I have several issues with this PR. I don't think this can work by relying on adaptive chunking code which has an unproven track record and was written before...