Implementing foreign data wrappers and avoiding n+1 querying

From: David Gilman <davidgilman1(at)gmail(dot)com>
To: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Implementing foreign data wrappers and avoiding n+1 querying
Date: 2022-12-22 00:31:30
Message-ID: CALBH9DDS6hwnG3VLiX1vqcM95f=A9Gm-Pj5_1+hm4OhAqszrmQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

When a fdw table participates in query planning and finds itself as
part of a join it can output a parameterized path. If chosen, Postgres
will dutifully call the fdw over and over via IterateForeignScan to
fetch matching tuples. Many fdw extensions do network traffic, though,
and it would be beneficial to reduce the total number of queries done
or network connections established.

Is there some path that can be emitted by the fdw, or some other
technique, to get the query planner and everything else to handle
batching the tuples returned by the outer relation? For example, once
batched the fdw extension could send the equivalent of a WHERE row IN
(a, b, c), or maybe even WHERE row BETWEEN a AND c to the foreign
system, and either the fdw callback or a subplan does the rechecking
to match up the returned foreign tuples with the local ones.

One thought is that it might be possible to abuse the async support
for fdws to accomplish this. Your fdw could accept async requests, sit
on them until some threshold is crossed, do the actual query and feed
them back into the executor when the results are back. However, from
what I can tell the async interface has no way to tell the ForeignScan
that it won't get any more async requests, so there's no way to force
flush the final batch of queries.

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Dan Langille 2022-12-22 00:55:13 Re: tsvector not giving expected results on one host
Previous Message Benedict Holland 2022-12-21 23:57:48 Re: Regd. the Implementation of Wallet (in Oracle) config equivalent in postgreSQL whilst the database migration