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

Partitioning by datetime #347

Open
bjgiraudon opened this issue Feb 5, 2025 · 2 comments
Open

Partitioning by datetime #347

bjgiraudon opened this issue Feb 5, 2025 · 2 comments

Comments

@bjgiraudon
Copy link

Hi, I am currently running a database with ~60000 STAC Collections.

By default, partitioning in done by "collection", which has worked well in the past but is causing problems in this instance.

I quickly run way too many partitions and queries get super slow, pretty fast.
I wanted to edit partitioning, for a datetime-based approach, for example having a partition per week.
However, it seems like it's not working because pgstac still tries to create _items_XXXXX partitions when loading items into the DB.

So my question is : how can I update the database parttioning to match my needs ?

Thanks :)

@bitner
Copy link
Collaborator

bitner commented Feb 10, 2025

@bjgiraudon Unfortunately, right now, hard coded partitioning by collections is very deeply ingrained in how pgstac works and the partition automation scripts. I do not see any reasonable way that we could remove that limitation without a lot of work. In order to have fully managed partition experience, we make the concession of losing some flexibility.

@bjgiraudon
Copy link
Author

@bitner thanks for your answer.

Do you know how I could improve database transactions? My implementation is quite heavy on writing, not so much on reading. I have 60k+ collections. Right now, my workflows are stuck on write operations, presumably looking for partitions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants