Re: Implementing foreign data wrappers and avoiding n+1 querying

Поиск
Список
Период
Сортировка
От David Gilman
Тема Re: Implementing foreign data wrappers and avoiding n+1 querying
Дата
Msg-id CALBH9DAhF1PBLPmkJ699H3haQ4A-PdhreK2AqckgrAizeMca-A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Implementing foreign data wrappers and avoiding n+1 querying  (David Rowley <dgrowleyml@gmail.com>)
Ответы Re: Implementing foreign data wrappers and avoiding n+1 querying  (Brad White <b55white@gmail.com>)
Список pgsql-general
I apologize that my post was not super clear, I am thinking about implementing a fdw from scratch, and the target database is one of those NoSQL databases where you have to send JSON over a HTTP connection for each query.

I have reviewed the postgres fdw code to see how it works and to see what's possible. Although it probably wouldn't benefit as much from this sort of thing (yay to postgres' design!) It could possibly still benefit a bit, which makes me wonder if it can't be done with the current planner nodes it might be a worthy improvement to add support for this.

On Wed, Dec 21, 2022, 10:57 PM David Rowley <dgrowleyml@gmail.com> wrote:
On Thu, 22 Dec 2022 at 13:31, David Gilman <davidgilman1@gmail.com> wrote:
>
> 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.

Sounds like you might be looking for fdw_startup_cost [1].

David

[1] https://www.postgresql.org/docs/current/postgres-fdw.html

В списке pgsql-general по дате отправления:

Предыдущее
От: hubert depesz lubaczewski
Дата:
Сообщение: Re: trouble writing plpgsql
Следующее
От: "Peter J. Holzer"
Дата:
Сообщение: Re: Regd. the Implementation of Wallet (in Oracle) config equivalent in postgreSQL whilst the database migration