Table editor loads all the data

[laurentS]

Bug report

Describe the bug

When opening a table in the table editor, a ttps://project_id.supabase.co/rest/v1/table_name?select=* is issued which seems to query ALL the rows of the table. Right now, looking at a table which downloads 80MB (6.7MB gzipped) on each refresh (the table has 142k rows and 16 columns).
It feels like pulling only 100 rows would be enough for the display in most cases.
Trying another table (135 cols, 220k+ rows), the request doesn't actually complete, and I get a timeout / HTTP 524 error code which seems to cause the backend (or cloudflare?) to fail

To Reproduce

1. Create a "heavy" table (see metrics above) and upload a bunch of data to it (via postgres tools)
2. Try to open the table in the editor
3. watch it be slow or unresponsive or even "restart"

Expected behavior

The editor should probably limit how many rows it loads to something a lot smaller to stay responsive. 100 seems like a good starting point, or something user configurable?

System information

• OS: Debian sid
• Browser firefox 84

[inian]

Hey @laurentS, good spot!

This was required for implementing pagination in the dashboard and figuring out how many pages there were. postgrest-js just launched support for row counts, so this can be done in a better way than to just fetch all the data.

[storytracer]

I can confirm this problem. I have a very large table with 15+ millions rows. Connecting directly from a desktop client to the Postgres DB works without issues. But the table editor in the Supabase Web UI won't load anymore, giving the error "Error loading tables – undefined". Also, the API docs will not generate.

[inian]

Hi, this enhancement has been deployed and the table editor should only be loading 100 rows at a time.

[laurentS]

@inian this works for me, glad to see the page being a lot more responsive now that it's not loading everything each time. Just a note that there's a minor bug in the pagination:
I'm seeing IDs 0-100 (included both ends), then 100-200, then 200-300. So there's 1 row that is shown twice (id=100, 200, 300...).

[inian]

Good catch Laurent! I have fixed this and it should go out in the next release.