From: | Octavio Alvarez <alvarezp(at)alvarezp(dot)ods(dot)org> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Slow queries from information schema |
Date: | 2009-02-14 18:13:07 |
Message-ID: | 1234635187.17840.27.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
I'm aware you already know that information_schema is slow [1] [2], so I
just want to expose/document another case and tests I did.
I'm using the following view to check what tables depend on what other
tables.
CREATE VIEW raw_relation_tree AS
SELECT
tc_p.table_catalog AS parent_catalog,
tc_p.table_schema AS parent_schema,
tc_p.table_name AS parent_table,
tc_c.table_catalog AS child_catalog,
tc_c.table_schema AS child_schema,
tc_c.table_name AS child_table
FROM
information_schema.referential_constraints AS rc
NATURAL JOIN information_schema.table_constraints AS tc_c
LEFT JOIN information_schema.table_constraints AS tc_p ON
rc.unique_constraint_catalog = tc_p.constraint_catalog AND
rc.unique_constraint_schema = tc_p.constraint_schema AND
rc.unique_constraint_name = tc_p.constraint_name
;
test=# select count(*) from raw_relation_tree;
count
-------
11
(1 row)
An EXPLAIN ANALYZE for a simple SELECT on each of the FROM tables give:
referential_constraints: ~9ms.
table_constraints: ~24ms.
The result, on the above view: ~80ms. Fair enough. But if I apply a
condition:
SELECT * FROM ___pgnui_relation_tree.raw_relation_tree WHERE
parent_schema <> child_schema;
it takes ~2 seconds (!) to complete.
I tried using an alternate table_constraints definition by creating my
own view and changing UNION to UNION ALL (as per [2]) The results were:
table_constraints using UNION ALL has the same number of rows as the
UNION version.
table_constraints now take about 4 ms (as expected).
VIEW raw_relation_tree is now 110 ms.
VIEW raw_relation_tree WHERE parent_schema <> child_schema: 3.3 sec.
EXPLAIN results are way too long to post here. If it is ok, I'll gladly
post them.
Using 8.3.6.
[1] http://archives.postgresql.org/pgsql-bugs/2008-12/msg00144.php
[2]
http://archives.postgresql.org/pgsql-performance/2008-05/msg00062.php
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Staubo | 2009-02-14 18:26:37 | Re: I/O increase after upgrading to 8.3.5 |
Previous Message | Peter G. | 2009-02-14 16:11:43 | Retrieving data from PostgreSQL to .NET application – performance test – surprising results |