I am trying to pull a SQL server database table wh...
# general
p
I am trying to pull a SQL server database table which has about 300+ million rows. It is partitioned based on an index integer column with partition number set around 50. The query seems to be hang completely and I am seeing no parquet file written. I can query the data using SQL management studio. Any idea what could be wrong and any suggestions how to debug the hang issue?
c
Hey @Phil Chen, couple of questions: • which version of daft are you using? • Are you able to see the executed queries on the server side?
p
@Colin Ho sorry for the late response. We did a little more digging from the database server side and It appears this is caused by the window function PERCENTILE_DISC missing OVER clause that we recently fixed in 0.3.9. I rollback to 0.3.8, everything works fine. I guess the generated query using the window function is not scale well for large table. So we need find a more scalable to do the partition, or we should simply stick to simpler fallback method that in 0.3.8.
If possible, could we disable using the Window function for now if it is not easier to make it more scalable to large table. As it is now preventing us from upgrading daft.
c
Yes, that makes sense, thank you for digging! We originally implemented the PERCENTILE window function to calculate even partition bounds and prevent data skew, but looks like it is not scalable. Apologies for the inconvenience. I will make the change to use the simpler fallback method that works for you.
👍 1
p
For the reference, this is related to this fix: https://github.com/Eventual-Inc/Daft/issues/3075
For the sake of discussion, for compute partition boundaries for a large tables, we could consider implementing a probabilistic algorithm that based on sampling of the table to estimate partition boundary to avoid using Windowing and Sorting over the entire table. This will allows trade off btw accuracy and computational complexity (both time and space complexities). The parameter to control this trade off is the sampling size. The large the sampling size, the more accurate, but it will be more computational complex. If smaller sampling size will be more likely to have uneven sized partition (skew).
For now, I think support only the fallback partition scheme is good for most use cases where data is already roughly evenly distribute across partition column.
c
Thank you for the suggestion! I created an issue for this: https://github.com/Eventual-Inc/Daft/issues/3245, in the meantime, I will make the fix to support the fallback partitioning scheme.
p
Thats great, thank you @Colin Ho!