You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi,I paid attention to zksql when I was looking through the paper recently and reviewed TPC- H based on the code in the paper, I found that performing a join operation, which was not mentioned in the paper, would lead to memory overflow, and suggested that this project could measure the program's running maximum memory after implementing the sql inner_join operator, and it would be a more convincing proof of the correctness of the program selection. Good luck!
The text was updated successfully, but these errors were encountered:
Thank you very much for your reply, can I think that the current optimization scheme after implementing the join operator lies in the fact that it should be too large for the Cartesian product generated after the join operation, resulting in too large a PROOF SIZE. It seems that using VOLE in the head can reduce the memory usage since only one calculation is needed. Of course proof of sql will have a better implementation, looking forward to the project's continuous update, I can learn a lot of knowledge from proof of sql.Thank you~
#Suggestion:
Measure the peak memory usage and proof size after adding the query plan to the join algorithm to generate the corresponding proof.
Hi,I paid attention to zksql when I was looking through the paper recently and reviewed TPC- H based on the code in the paper, I found that performing a join operation, which was not mentioned in the paper, would lead to memory overflow, and suggested that this project could measure the program's running maximum memory after implementing the sql inner_join operator, and it would be a more convincing proof of the correctness of the program selection. Good luck!
The text was updated successfully, but these errors were encountered: