Matvey Arye

Yes, in promscale we found that doing `INSERT INTO metric_table(time, value, series_id) SELECT * FROM unnest($1::TIMESTAMPTZ[], $2::DOUBLE PRECISION[], $3::BIGINT[]) a(t,v,s)` is much more efficient than `INSERT INTO ... VALUES (...)`...

@erimatnor the problem is this won't help with Promscale performance as Promscale needs ON CONFLICT. I think writing a unnest in C that undoes just one dimension shouldn't be too...

It seems like the low-hanging fruit is optimize either: 1) the inserting non-arrays but supporting ON CONFLICT. 2) inserts including arrays but without ON CONFLICT. I'd argue for the former.

FWIW i'd be super happy with having both optimizations the unnest approach for non-arrays and/or copy otherwise. I do understand the need for generality. I am just arguing against ONLY...

I did not realize the max dimensions was so small (only 6)

This warning is expected. It is harmless. We will look at getting rid of it in the future.

I'll add tests if we agree to go forward with this approach.

Thanks for this report. Do you think it's better to exit the process or recover internally?

Hey @thmang82 sorry for the late reply. In PostgreSQL, primary keys are actually /not/ clustered on disk (data is not ordered by primary key in the heap). So there is...

^ @antekresic's chart looks right. I would suggest changing `0.5.0 and above` to `0.5.x` for the extension version since I am not sure we want to commit to indefinite backwards...