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

Cache not working when using as standalone extension #480

Closed
miguelbranco80 opened this issue Jul 9, 2024 · 1 comment · Fixed by #487
Closed

Cache not working when using as standalone extension #480

miguelbranco80 opened this issue Jul 9, 2024 · 1 comment · Fixed by #487
Assignees

Comments

@miguelbranco80
Copy link

When using steampipe-postgres-fdw as a standalone extension, the cache does not seem to be working.

When running in TRACE mode, there's an indication that the connection cache was cleared. This is visible if we do multiple queries using e.g. psql. There is a significant delay due to this. Even with STEAMPIPE_CACHE off, queries are slower than they should be (as I believe there's some upfront work - schema caches? - that is also re-done everytime.)

While digging over the codebase of hub_local.go I noticed that UpdateConnectionConfig was being called everytime, and this lead to the connection cache being cleared here.

As an experiment, I tried modifying the UpdateConnectionConfig to add the an if statement:

func (l *HubLocal) UpdateConnectionConfig(connectionName, configString string) error {
	log.Printf("[INFO] HubLocal UpdateConnectionConfig: connection: %s, config: %s", connectionName, configString)

   // BEGIN MODIFICATION
    if conn, ok := l.connections[connectionName]; ok && conn.Config == configString {
        return nil
    }
   // END MODIFICATION

   [ ...]

By adding the if statement, we prevent the call to l.plugin.UpdateConnectionConfigs, which triggers the connection cache invalidation.

I'm happy to contribute a PR with the change, but would need to understand first if this is going in the right direction. I am not yet very familiar with the codebase and just began exploring it in the past few days.

@pskrbasu
Copy link
Contributor

pskrbasu commented Aug 1, 2024

Thank you for raising this issue @miguelbranco80.

We have found the fix for this, basically the ProcessImportForeignSchemaOptions is unnecessary here (which led to the clearing of connection cache).

We will release the fix soon.

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

Successfully merging a pull request may close this issue.

2 participants