AlloyDB per PostgreSQL utilizza il precaricamento degli indici per velocizzare le query che leggono un intervallo di righe tramite un indice B-tree. Il precaricamento dell'indice è abilitato per impostazione predefinita nelle istanze AlloyDB e AlloyDB Omni che eseguono PostgreSQL 17 e versioni successive. Non è necessario impostare flag, ricreare indici o modificare l'applicazione o le query SQL per trarne vantaggio.
Come funziona il precaricamento dell'indice
Quando una query analizza un intervallo di valori tramite un indice, ad esempio un predicato BETWEEN o una clausola ORDER BY ... LIMIT su una colonna indicizzata, l'analisi legge le pagine dell'indice e le pagine della tabella a cui puntano le voci dell'indice.
Queste pagine di tabella sono spesso sparse nello spazio di archiviazione. In PostgreSQL standard,
la scansione legge queste pagine una alla volta, quindi quando le pagine non sono già in
memoria, la query impiega la maggior parte del tempo in attesa dell'I/O dello spazio di archiviazione.
Con il precaricamento dell'indice, AlloyDB esamina la scansione in esecuzione sia sull'indice che sulla tabella e legge in parallelo le pagine di cui la scansione avrà bisogno. AlloyDB prepara le pagine precaricate nella cache SSD locale dell'istanza, in modo che, quando la scansione richiede una pagina, questa venga fornita dallo spazio di archiviazione locale veloce anziché da quello remoto. Le pagine precaricate vengono gestite al di fuori dei buffer condivisi di PostgreSQL, pertanto il precaricamento non riduce la cache del buffer disponibile per altre sessioni.
Il precaricamento dell'indice include le seguenti misure di sicurezza per evitare di aggiungere overhead alle query che non possono trarne vantaggio:
- Il precaricamento si interrompe al limite di una clausola
LIMIT, quindi la scansione non legge le pagine oltre le righe restituite dalla query. - Per le scansioni solo indice sugli indici di copertura, AlloyDB precarica solo le pagine di indice e non legge le pagine della tabella.
- Le query che restituiscono una singola riga, come le ricerche di chiave primaria, non attivano il precaricamento.
Vantaggi per i workload
Il precaricamento dell'indice è più utile quando il set di lavoro è più grande della memoria dell'istanza e le query leggono molte righe tramite un indice B-tree. Di seguito sono riportati alcuni esempi di query che traggono vantaggio da questa funzionalità:
- Query su intervalli di colonne indicizzate di timestamp, date o numeri, ad esempio report su una finestra temporale.
- Query che restituiscono molte righe per una chiave, ad esempio la cronologia degli ordini di un cliente.
- Join in cui il lato interno è una scansione dell'indice che restituisce molte righe.
- Query analitiche che leggono intervalli di grandi dimensioni da tabelle orientate alle righe.
Le query i cui dati sono già presenti nei buffer condivisi e le ricerche su singole righe hanno le stesse prestazioni con o senza precaricamento.
Prefetching nei piani di esecuzione
Per visualizzare l'effetto del precaricamento dell'indice su una query, esegui la query con EXPLAIN (ANALYZE, BUFFERS). Le pagine che il precaricamento carica nella cache dell'SSD locale vengono visualizzate come conteggi ultra fast cache hit sui nodi di scansione dell'indice del piano. Per saperne di più sulla lettura di questi contatori, consulta Ottieni e analizza i piani di esecuzione.