On Wed, Sep 20, 2017 at 9:44 AM, Thomas Munro <thomas.munro@enterprisedb.com> wrote: > 2. What queries in the 0008 patch are hitting lines that 0007 doesn't hit? > > I thought about how to answer questions like this and came up with a > shell script that (1) makes computers run really hot for quite a long > time and (2) tells you which blocks of SQL hit which lines of C. > Please find attached the shell script and its output. The .sql files > have been annotated with "block" numbers (blocks being chunks of SQL > stuff separated by blank lines), and the C files annotated with > references to those block numbers where A<n> = block <n> > partition_join.sql and B<n> = block <n> in partition_join_extras.sql. > > Then to find lines that B queries hit but A queries don't and know > which particular queries hit them, you might use something like: > > grep -v 'SQL blocks: .*A[0-9]' < joinpath.c.aggregated_coverage | \ > grep 'SQL blocks: .*B[0-9]' >
Thanks for this. It generates a lot of output (970 lines over all the coverage files). It will take some time for getting anything meaningful out of this. May be there's some faster way by looking at the lines that are covered by B but not A. BTW, I checked those lines to see if there could be any bug there. But I don't see what could go wrong with those lines.
I have also tried to find test cases in B which hits some extra line which is not hitting by A, with the help of results attached by Thomas in coverage.tarball_FILES. It took lot of time but I am able to find some test cases. which if adding in partition_join.sql
increasing no of lines hit by 14. but for hitting these 14 extra line attached patch is doing
900+ line inserts in partition_join.sql and partition_join.out file.
I have used gcov-lcov to find coverage for files changed by partition-wise-join patches
with and without attached patch which is below.
with existing partition_join.sql
partition_join.sql + some test cases of partition_join_extra.sql
