Hi Tom,
I agree that the query needs to be first correct, and second fast. I also
agree that this query works only if there are no duplicates among schemas
(if one chooses to create a table with the same names and index names and
constraint names in a different schema, this would not work). Provid
Arturas Mazeika writes:
> Thanks a lot for having a look at the query once again in more detail. In
> short, you are right, I fired the liquibase scripts and observed the exact
> query that was hanging in pg_stats_activity. The query was:
> SELECT
> FK.TABLE_NAME as "TABLE_NAME"
>
I
Hi Michael,
Thanks a lot for having a look at the query once again in more detail. In
short, you are right, I fired the liquibase scripts and observed the exact
query that was hanging in pg_stats_activity. The query was:
SELECT
FK.TABLE_NAME as "TABLE_NAME"
, CU.COLUMN_NAM
I'm unclear what you changed to get the planner to choose one vs the other.
Did you disable hashjoins? Without the full plan to review, it is tough to
agre with any conclusion that these particular nodes are troublesome. It
might be that this was the right choice for that part of that plan, but
imp
Hi Michael,
Thanks for the answer.
I agree that the tables behind the views makes the query processing
challenging. What makes it even more challenging to us is that this query
is generated by a third party library that we use to operationalize the
schema changes.
I am trying to figure out what
I believe that this is a planning problem with the number of tables/joins
involved in the query you have written. If you take a look at the
definition of the views in information_schema that you are using and read
about from_collapse_limit/join_collapse_limit, you may see that this is a
bit painful
