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

support for approximate counts in aggregates #1154

Open
0x777 opened this issue Dec 2, 2018 · 2 comments
Open

support for approximate counts in aggregates #1154

0x777 opened this issue Dec 2, 2018 · 2 comments
Assignees
Labels
a/api/graphql c/server Related to server c/v3-ndc-postgres Data connector for PostgreSQL k/enhancement New feature or improve an existing feature p/medium non-urgent issues/features that are candidates for being included in one of the upcoming sprints v3

Comments

@0x777
Copy link
Member

0x777 commented Dec 2, 2018

For example,

query {
  users_aggregate {
    aggregate {
      count
    }
  }
}

would result in an SQL query which will do a sequential scan.

Maybe we can natively support few tricks from https://www.citusdata.com/blog/2016/10/12/count-performance/

@0x777 0x777 added k/enhancement New feature or improve an existing feature c/server Related to server p/medium non-urgent issues/features that are candidates for being included in one of the upcoming sprints labels Dec 2, 2018
@KillianGDK-FDTI
Copy link

KillianGDK-FDTI commented Jan 5, 2022

Hello, it would be a super nice feature to have. In my app I have to wait dozens of seconds for each aggregate count.
An approximate instead will take less that a second and will be a breaking change for us.

Is there any news on that topic ?

Thanks again and congratz to all hasura team :)

@manasag manasag added the c/v3-ndc-postgres Data connector for PostgreSQL label Dec 27, 2023
@manasag
Copy link
Contributor

manasag commented Dec 27, 2023

This issue will now be reviewed and tracked as part of the Hasura V3 roadmap.

@manasag manasag added the v3 label May 22, 2024
hasura-bot pushed a commit that referenced this issue Sep 25, 2024
<!-- The PR description should answer 2 important questions: -->

### What

If a model has arguments, but they are all provided by presets, then
previously we would require users to pass an empty `args: {}` argument
like this:

```graphql
query MyQuery
  ActorsByMovieMany(args: {}) {
    actor_id
    movie_id
    name
  }
}
```

There is no need for this, so this PR loosens this restriction, by
providing a default empty value. This means users can also do the above
query with:

```graphql
query MyQuery
  ActorsByMovieMany {
    actor_id
    movie_id
    name
  }
}
```

Because both versions now work, this is a non-breaking change.

### How

Instead of just looking at number of arguments in schema generation,
consider which have been prefilled and provide a default empty value if
there is nothing a user could pass anyway.

V3_GIT_ORIGIN_REV_ID: cf184e42a114df782e1480a8f19548dda31e5992
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a/api/graphql c/server Related to server c/v3-ndc-postgres Data connector for PostgreSQL k/enhancement New feature or improve an existing feature p/medium non-urgent issues/features that are candidates for being included in one of the upcoming sprints v3
Projects
None yet
Development

No branches or pull requests

5 participants