Replies: 1 comment
-
| This crate might be of interest for cleaning up the glue code without compromising on performance: https://docs.rs/enum_dispatch/latest/enum_dispatch/ | 
Beta Was this translation helpful? Give feedback.
                  
                    0 replies
                  
                
            
  
    Sign up for free
    to join this conversation on GitHub.
    Already have an account?
    Sign in to comment
  
        
    
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
The implementation of column scans is a bit inelegant. The trait
ColumnScandefines the functionsposandnarrowwhich only make sense for those column scans which directly iterate through a column. However, every other type of column scan still has to provide an implementation (currently just resorts to aunimplemented!call). Furthermore, every new type ofColumnScanhas to be entered into theColumnScanEnumobject, which is tedious. A third issue is that in some cases, the type of theColumnScanis known (e.g. inTrieProjectone knows that the column scans areColumnScanReorder), but they are still stored as a vector ofColumnScanTs. In order to limit the amount of "unpacking" one has to do, currently, all functions specific to one type ofColumnScanare also implemented on theColumnScanEnumwhich panics if the function is called on the wrong type of column scan. However, it may be difficult to avoid this in general because sometimes we store several different types ofColumnScans in the same vector, e.g. inTrieJointhe scans could either beColumnScanJoinorColumnScanPass.To solving those problems you would probably:
ColumnScanEnumusedyn ColumnScanColumnScanTypeTenums for each type of column scanImplementing the
dynapproach can also be done first without the rest for testing the performance impact. In this case one would leave the extra functionsposandnarrowin the trait.Beta Was this translation helpful? Give feedback.
All reactions