gpdb
gpdb copied to clipboard
greenplum-db
Enable quicklz tests during ICW
- need to install libquicklz-devel in order to run configure with quicklz enabled before running ICW on CentOS
Co-authored-by: Jesse Zhang [email protected] Co-authored-by: Bradford D. Boyle [email protected]
Looks good. Except sql function get_ao_compression_ratio() seems not stable which causes CI build failure
select get_ao_compression_ratio('aoco_table_compressed_type') as quicklz_compress_ratio;
quicklz_compress_ratio
------------------------
- 17.17
+ 17.2
@ashwinstar I remember that you were involved in some work to make get_ao_compression_ratio stable by always zeroing out memory before doing compression. Whatever happened to that work?
@ashwinstar I remember that you were involved in some work to make
get_ao_compression_ratiostable by always zeroing out memory before doing compression. Whatever happened to that work?
Did you mean #7574 and #7448 ? Seems like both are merged to make the compression deterministic (provided that the compressor is fairly "frozen").
We observed consistently a compression ratio of 17.17 and that is why we changed the expected results. But the PR pipeline is showing the old value of 17.2.
@d and @bradfordboyle
What's the latest on this?
My understanding is that somebody from the server team was going to look into why the compression ratio was not always the same value. Either the test needs to be updated to check for a range of compression ratios or update the code so that the compression ratio is consistent.
@bradfordboyle so i tested the compression ratio..it was consistent across 1000 queries i fired to get compression ratio. However, On centos6 the value was 17.17 and on centos7 it was 17.2 but was consistent on the OS. The other test case which updates the compression ratio to 1.83 was consistent on centos6 and centos7. The PR pipeline failed as may be the test case were updated on centos6, whereas PR pipeline runs on centos7. Now why the compression ratio is different between centos6 and centos7, i don't know quite yet. The PR which fixed the consistency seemed agnostic to OS. Trying to dig in if i can find some useful insight into the difference.
@bradfordboyle Is this PR still needed to proceed ? Seems long time no activity, if no more action on this, is that OK to close ?
Given we ship with quicklz we do need coverage for it. So, we should try to complete this PR and ship it. Lets try to trace out what's remaining to get it to finish line.
Given this PR is not ready and needs more work, closing the same for now. We are tracking to complete this work and will revisit in near future, during that time will use this PR as reference.