Prefer estimated count using RPC (supabase)

  • uunicode-1362120626164203661

    unicodes

    4 days ago

    How to get the results of Prefer estimated=count but using RPC? I have a function with limit and offset but this doesn't work anymore with Prefer estimated count. A solution would be selecting all and then filter as per limit and offset but this isn't efficient for db, is there an efficient solution like Prefer?
  • lucasg-1362121282468057168

    Lucas G

    4 days ago

    Wouldn't you be passing those things as args to the formula instead?
  • You're making a db function call, not a standard GET request
  • uunicode-1362122129486909481

    unicodes

    4 days ago

    Hi Lucas! Yes, it is a Function to Select data from tables. Args are values that I provide as inputs, but I do not know the estimated size of the select without the limit. I need this value for pagination.
  • uunicode-1362122395795722260

    unicodes

    4 days ago

    I pass as args the limit and offset, but I need to return appended to the results the estimated size of all select without limit and offset, because Prefer with RPC isn't working.
  • lucasg-1362122543749660884

    Lucas G

    4 days ago

    Prefer is a header for PostgREST
  • It wouldn't do anything for a db function call
  • You'll have to implement the prefer logic into the call is what I meant
  • uunicode-1362123526185943080

    unicodes

    4 days ago

    I'm looking for an efficient way, the only solution I have now is counting all the select then filter as per limit and offset, but this isn't efficient because it doesn't limit the select. Do you know a solution of having a performant select with limit but in the same time having an estimated of values?
  • lucasg-1362126396637577317

    Lucas G

    4 days ago

    I'm not sure I understand the use case
  • lucasg-1362126847634309484

    Lucas G

    4 days ago

    You can do SELECT thing AS estimated_count in SQL
  • Which is similar, but it doesn't have all the convenience of PostgREST
  • lucasg-1362127258986221760

    Lucas G

    4 days ago

    I think you have to add in views and all that
  • uunicode-1362132474603503666

    unicodes

    4 days ago

    Thank you. I was looking to avoid the second select in order to have a faster response. I like the PostgREST way to estimate and the performance of selecting and join. Do you know if with a new version of the API will be possible to have more complex query ways?
  • uunicode-1362133178164314214

    unicodes

    4 days ago

    I was forced to use RPC because I need to select all the values from a table where the "date" equals with today, then showing the others from past and then the ones from future. This is possible with function but not with PostgREST. Tried to filter but isn't an ideal solution because it cuts of results if not included in the initial query.
  • lucasg-1362133916366143579

    Lucas G

    4 days ago

    How many items are you querying through? Are you using timestampz or something else
  • lucasg-1362134316670517460

    Lucas G

    4 days ago

    This doesn't sound like it should be a 'slow' call, though sometimes loading times are inevitable so we gotta add 'loading' UIs
  • lucasg-1362136115867287806

    Lucas G

    4 days ago

    When doing it in a call, can you not do:
    GET /table?date=eq.2025-04-16 or date=lt.2025-04-16 or date=gt.2025-04-16

Stop scrolling. Start building.

toddle is a visual web app builder that rivals custom code — but accessible to your entire team!

Try toddle — it's free!

© Copyright 2024 toddle. All rights reserved.