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

Postgres 11 partitions support #1160

Closed
lskrajny opened this issue Oct 1, 2019 · 14 comments
Closed

Postgres 11 partitions support #1160

lskrajny opened this issue Oct 1, 2019 · 14 comments

Comments

@lskrajny
Copy link

lskrajny commented Oct 1, 2019

Are there any work/plans to support declarative partitioning introduced in PostgreSQL 11?

Current behaviour is lets say i have got "fruit" table partitioned by type with separate partitions for each type ("apple", "banana", etc.)

Postgraphile generates schema for child tables and not for parent one :/

@benjie
Copy link
Member

benjie commented Oct 1, 2019

In general, features like this are added to PostGraphile in the following ways:

  1. Someone offers to write the functionality and works (hopefully with my input) to plan and introduce the feature, possibly over multiple PRs to keep review manageable.
  2. Someone wants the functionality and pays me to implement it. Theoretically multiple interested parties could "club together" to pay for the feature but this hasn't happened yet.
  3. I want the feature for something I am building, so I build it.
  4. Enough sponsors, contributors and users say that they want the feature that I dedicate my sponsored time to working on it.

Option 4 is how most things get done, but it takes a long time because my sponsored time also covers a lot of other duties, and because I have my own perceived priorities on which tasks or features should be built first. Excitingly, as my sponsorship levels grow, the rate of change in option 4 is increasing 🙂

The demand for this feature is not (yet) particularly high. People who are interested in this feature should use the 👍 emoji response on the above comment.

@ben-pr-p
Copy link

@ lskrajny you could always use smart comments + a view to force postgraphile to do the right thing – in this case it would be:

create view fruits as select * from fruit;

comment on table apple is '@omit';
comment on table bananas is '@omit';

@ab-pm
Copy link
Contributor

ab-pm commented Nov 18, 2019

Hi @lskrajny, I plan to work on #387 to introduce interfaces. While table inheritance is imo not the best way of representing shared fields between types in postgres, I do plan to cover it (or at least prepare for it). Aren't declarative partitions a very similar thing?
If you could post some examples of how you use declarative partitioning and how you would expect the generated schema to look like (in enough detail that I can use them as tests), I can have a look at those as well.

@wesselvdv
Copy link

I'd love partitions to become first class citizens.

@wesselvdv
Copy link

I am actually running into a similar issue with timescale Hypertables. This is chunking the table in multiple different partitions dynamically and this seems to awry with wal2json and live queries. Since the chance is reported for the chunk (child) instead of the hypertable itself. (parent)

@ghost
Copy link

ghost commented Dec 7, 2020

Hey @wesselvdv I'm also using timescale for my project and I'm thinking about migrating from prisma to graphile. Did you solve this issue, and have you ran into other problems with graphile+timescale?

@wesselvdv
Copy link

Hey @wesselvdv I'm also using timescale for my project and I'm thinking about migrating from prisma to graphile. Did you solve this issue, and have you ran into other problems with graphile+timescale?

Yes, I did solve this issue for subscriptions, and I didn’t run into any issues with queries or mutations with timescale. You can query hypertables perfectly fine.

@ghost
Copy link

ghost commented Dec 8, 2020

Nice. When you said subscriptions did you mean live queries too?

@wesselvdv
Copy link

Yes, that's what I mean. :-)

@benjie
Copy link
Member

benjie commented Apr 7, 2021

The issue is that where we filter on rel.relkind here:

https://github.com/graphile/graphile-engine/blob/1bc8cfefdab7a61fd7ad287bcdff66298352e308/packages/graphile-build-pg/src/plugins/introspectionQuery.js#L190

we're explicitly excluding partitioned tables (p) - see pg_class docs.

We should explicitly include the p tables, and explicitly exclude their partitions.

We also need to reflect the indexes.

@abner
Copy link

abner commented Feb 3, 2022

The issue is that where we filter on rel.relkind here:

https://github.com/graphile/graphile-engine/blob/1bc8cfefdab7a61fd7ad287bcdff66298352e308/packages/graphile-build-pg/src/plugins/introspectionQuery.js#L190

we're explicitly excluding partitioned tables (p) - see pg_class docs.

We should explicitly include the p tables, and explicitly exclude their partitions.

We also need to reflect the indexes.

There is some perspective to support partitions in postgraphile?

Here locally I patched the introspectionQuery.js to include the partitioned table (p) as suggested by @benjie

I would send a PR with this change.

msjonker added a commit to ECO-Parking-Technologies/postgraphile that referenced this issue Jul 12, 2022
msjonker added a commit to ECO-Parking-Technologies/postgraphile that referenced this issue Jul 12, 2022
@benjie benjie added the 🔁 revisit-in-v5 Not happy with this behaviour, but changing it is a breaking change. label Nov 2, 2022
@benjie benjie added 🔮 fixed-in-v5 and removed 🔁 revisit-in-v5 Not happy with this behaviour, but changing it is a breaking change. labels Sep 29, 2023
@benjie
Copy link
Member

benjie commented Sep 29, 2023

@benjie benjie closed this as completed Sep 29, 2023
@divya-sk
Copy link

I am raising one question addressing why Postraphile isn't exposing the parent table instead of the partition tables.

@benjie
Copy link
Member

benjie commented Mar 14, 2024

ref the identical question #1991

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

No branches or pull requests

7 participants