Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

First request speed #266

Open
alexnur opened this issue Mar 2, 2021 · 0 comments
Open

First request speed #266

alexnur opened this issue Mar 2, 2021 · 0 comments

Comments

@alexnur
Copy link

alexnur commented Mar 2, 2021

Hi!

I use multicorn.ldapfdw.LdapFdw.
If I have just connected (psql) to the database, then the first query to the external table takes a long time - 6-7 seconds. After that, any similar request takes 20ms. I disconnect from the server, reconnect. Again the first query to the outer table is 6-7 seconds. How can you speed up the first request so that the extension is already loaded before any new connection? I tried to specify in the configuration file postgresql.conf options:
shared_preload_libraries = 'multicorn'
local_preload_libraries = 'multicorn'
session_preload_libraries = 'multicorn'
and restart postgresql.
Nothing changed.
load 'multicorn' - doesn't help either.

https://multicorn.readthedocs.io/en/latest/implementing-tutorial.html

Foreign Data Wrapper lifecycle

_The foreign data wrapper associated to a table is instantiated on a per-process basis, and it happens when the first query is run against it.

Usually, postgresql server processes are spawned on a per-connection basis.

During the life time of a server process, the instance is cached. That means that if you have to keep references to resources such as connections, you should establish them in the init method and cache them as instance attributes._

I am not familiar with python. What exactly needs to be written in the _init method to have a fast first request?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant