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

Check for journal table existence slow on large PostgreSQL instance. #2

Open
Kharos opened this issue Feb 3, 2020 · 1 comment
Open
Labels
bug Something isn't working

Comments

@Kharos
Copy link

Kharos commented Feb 3, 2020

We have a Postgres aurora instance with ~600K tables. The metadata query that checks if the journal table already exists is very slow in this environment (~76 seconds on a "cold" database instance). This can cause query timeouts and lead to failed service deployments.

The query used by PostgresqlTableJournal is the generic sql metadata query, it is inherited from TableJournal. We could solve the problem by inheriting from PostgresqlTableJournal and replacing the query with a postgres specific query:

        protected override string DoesTableExistSql()
        {
            string tableFullName = string.IsNullOrEmpty(SchemaTableSchema) ? UnquotedSchemaTableName : (SchemaTableSchema + '.' + UnquotedSchemaTableName);
            return $"SELECT CASE WHEN to_regclass('{tableFullName}') IS NOT NULL THEN 1 ELSE 0 END";
        }

This query takes about 8 ms on a "cold" database instance.

The to_regclass function was added in PostgresSQL 9.4. Versions before 9.4 are no longer officially supported, so it might be worthwhile to put this fix into PostgresqlTableJournal.

@Kharos Kharos added the bug Something isn't working label Feb 3, 2020
@Kharos Kharos changed the title Check if table exksgs Check if table exists slow on large postgres instances Feb 3, 2020
@Kharos Kharos changed the title Check if table exists slow on large postgres instances Check for journal table existence slow on large PostgreSQL instance. Feb 3, 2020
@Kharos
Copy link
Author

Kharos commented Nov 7, 2023

I just stumbled over this in our code and decided to check if we still need to keep our workaround code... turns out yes, we do.

@droyad droyad transferred this issue from DbUp/DbUp Jan 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Status: Bugs
Development

No branches or pull requests

1 participant