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

Partitioned tables #17

Open
ptman opened this issue Jan 14, 2025 · 3 comments
Open

Partitioned tables #17

ptman opened this issue Jan 14, 2025 · 3 comments
Assignees
Labels
bug Something isn't working needs-more-information Further information is requested

Comments

@ptman
Copy link

ptman commented Jan 14, 2025

Have you got any ideas how to handle partitioned tables? I'm thinking of our usecase, but I believe it to be quite common. Range-based partitioning by timestamp column. In our case, monthly partitions for some tables.

Dump at least dumps the partitions, which isn't that useful. We also use sqlc which then ends up creating structs for the partitions.

@peterldowns
Copy link
Owner

peterldowns commented Jan 14, 2025

Sorry, I don't understand the question. The most helpful explanation would be an example scenario like this:

  • Given some schema...
  • Pgmigrate currently does X when you run Y commands ...
  • But you'd rather it did Z

I haven't worked much with partitioned tables so I'm sure that there is a way pgmigrate could be improved for your use case.

@peterldowns peterldowns added bug Something isn't working needs-more-information Further information is requested labels Jan 14, 2025
@peterldowns peterldowns self-assigned this Jan 14, 2025
@ptman
Copy link
Author

ptman commented Jan 14, 2025

Suppose we have a schema like this:

create table events (
    created timestamp with time zone not null default now(),
    event text
) partition by range (created);

create table events_p20250101 partition of events for values from ('2025-01-01 00:00:00Z') to ('2025-02-01 00:00:00Z');

Fixing the dates in the schema migrations does not make sense. But they will exist in pg when the schema gets dumped. Partitions don't really describe the schema, the shape of the data. They are an implementation detail and should be managed separately from migrations.

So I propose a way to either not dump tables that are partitions of other tables or some other way to ignore specific tables (with a regex?) to get the same end result.

@ptman
Copy link
Author

ptman commented Jan 16, 2025

Oh, also, dump loses the partition by range so information doesn't roundtrip 100%.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working needs-more-information Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants