Estoy desarrollando una colección de envoltorios de datos extranjeros usando multicorn y me encontré con un problema con el procesamiento por lotes de datos.
Entonces, tengo dos tablas externas, search y data , cada una respaldada por un contenedor de datos externos que estoy escribiendo.
Necesito hacer una unión básica en estas tablas:
SELECT data.* FROM search, data WHERE search.data_id = data.id AND search.term = 'search for this pls' Esto funciona, pero hay un problema en el fdw de data que puede enviar consultas por lotes al servidor. Si la tabla de search devuelve 5 ID para una búsqueda dada, entonces el fdw data se ejecuta una vez para cada uno de esos ID. La API que respalda los data fdw es capaz de procesar muchas identificaciones en una sola solicitud.
Los siguientes trabajos:
SELECT data.* FROM data WHERE id in ('2244', '31895') En este caso, el fdw data recibe una matriz de ambos identificadores y puede realizar una solicitud.
¿Hay alguna manera de hacer que la unión funcione donde el fdw data tiene la oportunidad de procesar lotes de ID para una solicitud?
¡Gracias!
Debería mirar el resultado de EXPLAIN para su consulta, y luego probablemente verá que PostgreSQL está realizando una combinación de bucle anidado , es decir, escanea la search de las filas coincidentes, y para cada fila de resultados escanea data en busca de filas coincidentes.
PostgreSQL tiene otras estrategias de combinación como combinaciones hash , pero para eso tendría que leer toda la tabla data , lo que probablemente no sea una victoria. Es posible que desee probarlo off enable_nestloop y probando el rendimiento de las consultas. Si eso es una mejora, es posible que desee ajustar los valores de costo para el escaneo de la tabla externa en los data para reflejar los altos "costos de inicio" para que el planificador se vuelva más reacio a elegir una unión de bucle anidado.
No existe una estrategia de unión como la que propones; si bien puede ser una victoria para las uniones de FDW, no ofrece ventajas en las uniones regulares. Entonces, si la estrategia de unión que imagina es realmente la óptima, primero tendría que obtener los data_id de search , construir una consulta de data e implementar la unión en la aplicación.