Did you tested compression change on already populated datab

Question

Did you tested compression change on already populated database and is there need to execute some compaction or some other action to have data available for query

wey · Answer

The compression algo change shouldn t impact the query have you got a chance to trigger compaction

Goran Cvijanovic · Answer

I use only automatic compactions not forcing with explicit command for compaction

Goran Cvijanovic · Answer

I found that issue I have is related to Index which doesn t return all records matching index using LOOKUP but FETCH ing data by VertexID returns that record

wey · Answer

Checked with storage guys and it looks like auto compaction time out due to the compression algorithm change Could you trigger a manual compaction

Goran Cvijanovic · Answer

I can but how it will help with that indexes problem that LOOKUPs not having all data in index

Goran Cvijanovic · Answer

I ve noticed that executing query with WHERE clause with == or STARTS WITH abcdefgh didn t return all rows of data Then I experimented with STARTS WITH abcdef and got some larger number of rows then repeating query with STARTS WITH abcdefgh returns all rows which match the where clause Looks like repair on read but don t know what actually happened I can see some activity on storage which produce some increased reads writes like some background process started after I reverted changes for leveled compression parameter and restarted storaged services on all nodes on cluster

wey · Answer

It s 3 3 0 or what is the storage client timeout configuration in your cluster

Goran Cvijanovic · Answer

Yes it is 3 3 0 ``` storage client timeout storage client timeout ms=60000```

wey · Answer

Dear < Goran Cvijanovic> let s continue the thread in DM here to enable involving other guys later Timed out in 60 secs is quite abnormal may I know if it s HDD or SDD

wey · Answer

The log level was v4 by default or you just switched it so now