Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

R-tree serialization support #342

Open
pomadchin opened this issue Apr 13, 2022 · 2 comments
Open

R-tree serialization support #342

pomadchin opened this issue Apr 13, 2022 · 2 comments
Labels
question Further information is requested

Comments

@pomadchin
Copy link

pomadchin commented Apr 13, 2022

R-tree serialization could be a pretty nice extra feature to support as a part of this fantastic tiny library.

Is there any interest in such kind of functionality support, or that was intentionally not implemented? Could be nice to establish / contribute into some sort of a standard for the R-tree serialization format (if there is no such yet).

// definitely a feature request / enhancement / help wanted issue

@plokhotnyuk
Copy link
Owner

Hi, Grigory!

I understand that building R-tree can be faster from serialized form, but it will require serialization of all user's entries.

Could you please, describe your case with more context to avoid XY problem?

@pomadchin
Copy link
Author

pomadchin commented Apr 14, 2022

Hi Andriy,

Thanks for replying that fast!

The use case is in building an index for the parquet file of geometries and persisting it, so we are not rebuilding it every time. The leafs of a tree will contain file block id(s) which later on can be used to perform reads.

I don’t need serialization immediately (it was resolved in a bit different fashion, I can tell you more but it seems like the out of scope conversation) and also don’t have any capacity to work on it.

But conceptually the idea of an efficient persistent index is of a significant interest to me: I have a feeling that such index may work way faster than the inbuilt parquet reader predicates api; I could also be wrong since that’s unclear what benefits we really get with it until we try, the cons are obvious though.

@plokhotnyuk plokhotnyuk added the question Further information is requested label Apr 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants