Hi,
Is there any way for the data writes/insertion while the compression is running. Unlocking the current uncompressed child table or main hypertable?
Configuration:
The chunk time interval is 1 day
Compression time was 15 minutes for 1 day of data
TimescaleDB version is pg16.3-ts2.15.2 and running on k8
Compression policies are default one: Compression Policy [10**]
Issue: Data insertion pauses during compression, interrupting real-time data flow.
I have already gone through these open issues so is there any way to do some setting to resolve or any hack?
opened 05:24PM - 22 Nov 20 UTC
closed 02:02PM - 21 Oct 21 UTC
question
Hello. When I decompress one chunk in next way
```sql
SELECT decompress_chunk(… '_timescaledb_internal._hyper_1_67_chunk');
```
All table is locking. Is there are any way to decompress chunk without locking of all table?
TSDB version: 1.7.1, PostgresSQL 12.3.
opened 04:45AM - 10 Dec 20 UTC
performance
compression
feature-request
locking
**Relevant system information:**
- OS: Debian 9
- PostgreSQL version (output… of `postgres --version`): postgres (PostgreSQL) 12.4 (Debian 12.4-1.pgdg90+1)
- TimescaleDB version (output of `\dx` in `psql`): timescaledb | 2.0.0-rc4
- Installation method: apt from packagecloud.io
**Describe the bug**
When compressing a chunk with `compress_chunk()`, after a certain point in the process, any queries with `chunks_detailed_size()` will block (possibly other metadata information queries as well, not sure).
**To Reproduce**
Steps to reproduce the behavior:
1. Have a multi-node cluster (not sure if necessary, but that's what I'm using)
2. On access node: `select compress_chunk('mychunk');`
3. On access node: While running, periodically do `select * from chunks_detailed_size('mytable')`
**Expected behavior**
Successful response in a short amount of time.
**Actual behavior**
On the data node:
```
Dec 10 03:48:49 ded4077 postgres[29867]: [38-1] pid=29867 db=edgestats user=postgres rhost=1.1.1.70 app=timescaledb tid=4/3050 sid=5fcfdb10.74ab LOG: process 29867 still waiting for AccessShareLock on relation 3424460 of database 16386 after 1000.110 ms
Dec 10 03:48:49 ded4077 postgres[29867]: [38-2] pid=29867 db=edgestats user=postgres rhost=1.1.1.70 app=timescaledb tid=4/3050 sid=5fcfdb10.74ab DETAIL: Process holding the lock: 14771. Wait queue: 29867.
Dec 10 03:48:49 ded4077 postgres[29867]: [38-3] pid=29867 db=edgestats user=postgres rhost=1.1.1.70 app=timescaledb tid=4/3050 sid=5fcfdb10.74ab CONTEXT: PL/pgSQL function _timescaledb_internal.chunks_local_size(name,name) line 3 at RETURN QUERY
Dec 10 03:48:49 ded4077 postgres[29867]: [38-4] pid=29867 db=edgestats user=postgres rhost=1.1.1.70 app=timescaledb tid=4/3050 sid=5fcfdb10.74ab STATEMENT: SELECT * from _timescaledb_internal.chunks_local_size( 'public', 'mytable' );
```
...eventually timing out due to `statement_timeout` (in my case, 5 minutes).
**Additional context**
While I doubt it would be possible to not block at all, I think the blocking time should be reduced to a few seconds at most.
Also, I’m thinking about decreasing the chunk time interval. If I reduced the time interval should it affect read queries? and what should be the ideal chunk time interval?