- Shipped
- 19 agosto 2026 alle ore 16:19 UTC
- Author
- Kamo
- Commit
- 9b3ad2c
/api/send ha preso 1.8-7.9 s per la maggior parte degli indirizzi e ms monodigit per alcuni, che non è un problema di carico — è la forma della query geolite. getLocation() è atteso prima che l'evento sia scritto, in modo che la latenza è stata pagata dal browser su ogni evento tracciato, e sul sito di marketing è stato pagato due volte perché il tracker attende il beacon prima di navigare. DOVE rete start <= $1 E network end >= $1 ORDINANZA DA network start DESC LIMIT 1 legge come indice cercare e non è uno. Con idx geolite blocks range asc il planner cammina l'indice all'indietro dall'indirizzo e porta ogni riga alla filtro. I blocchi non sono sovrapposti e ordinati, quindi l'unica riga che può mai match è il primo visitato — e quando la gamma di questa riga termina sotto l'indirizzo (un intervallo non legato, o qualsiasi indirizzo oltre la fine di un blocco) ogni riga precedente non riesce lo stesso test, quindi la scansione viene eseguita all'inizio di un tavolo da 5,8M-row prima Non restituire nulla. Alla ricerca di quel singolo candidato prima e test network end dopo restituisce esattamente le stesse righe. Misurata contro la tabella dal vivo: 47.181.8.84 1807 ms -> 7 ms US 208.67.222.222 7871 ms -> 5 ms US 93.184.216.34 4441 ms -> 6 ms US 203.0.113.7 7193 ms -> 6 ms (senza corrispondenza, correttamente) Nessun cambiamento di schema: l'indice di cui questo ha bisogno esiste già. Anche scende il 26257 porto fallback. CockroachDB è in pensione, ma quel porto ancora risposte, quindi un GEO DATABASE URL senza una porta esplicita connetterebbe felicemente e poi non riescono a trovare i tavoli piuttosto che rifiutarsi ingiustamente.