There's no local D1 yet? I'm a bit noobie with wrangler, so it was my perception that --remote uses
There's no local D1 yet? I'm a bit noobie with wrangler, so it was my perception that --remote uses the production.
--local to d1 execute toorows_written and rows_read in the metadata for every query. Documentation landing soon. e.g.
created_at column of a users tableSELECT * FROM users WHERE created_at = ?1 - that will use the index to look up the rows in the users table. This means there is a read on the index, and then a (MUCH SMALLER) read on the users table as you no longer have to do a full scan for the row(s) matching your created_at filter.users table, if your query only matches one row)
SELECT * FROM table LIMIT N - yes. But if you have a filter like a WHERE or HAVING clause, then you have to scan more rows to match the filter, since your table isn't necessarily ordered.ORDER in that query. But it has to scan the table somehow - usually a binary search. It's going to keep searching (scanning) until it has matched all possible records, or hit the LIMITLIMIT 10ORDER BY <some_date_column> queries. I probably need to add this to the docs.SQL LIKE? 
rows_written and rows_read and I am kinda surprised to find written rows in a SELECT query
➜ wrangler d1 execute db-enam --command "INSERT INTO users(email_address,created_at,deleted,settings) VALUES ('me@example.com,', 1687904983, null, '{}')" --json
[
{
"results": [],
"success": true,
"meta": {
"duration": 0.17432300001382828,
"size_after": 45137920,
"rows_read": 0,
"rows_written": 2 // Two rows: one to the table, and one to the index as there's an index on created_at for this table
}
}
]➜ wrangler d1 execute db-wnam --command "SELECT * FROM [Order] WHERE ShipRegion LIKE '%Western%' LIMIT 10" --json | jq '.[].meta.rows_read'
18 <-- we had to scan 18 rows to find 10 that matched our filter