Closed p-a-s-c-a-l closed 9 years ago
The _csw_create_view_forpycsw.sql script for creating the view is available here: https://github.com/switchonproject/cids-custom-switchon-server/tree/feature/5-meta-data-import/src/model/scripts
The materialized view is currently not in use, since a) the performance improvements are negligible and b) update triggers for the materialized view do not yet exist (see also https://github.com/switchonproject/cids-custom-switchon-server/issues/9)!
Integrated branch 'bug/7-database-performance-issues (9340795c952e08f171c0728425c2081e06c44d65)' into 'dev (a59903aece4df502016ad3b0fef70b64517214ec)' -- Build 37
great! this was one of the thing I thought would be very useful.
On Wed, Mar 4, 2015 at 5:44 PM, ci-cismet-de notifications@github.com wrote:
Integrated branch 'bug/7-database-performance-issues (9340795 https://github.com/switchonproject/cids-custom-switchon-server/commit/9340795c952e08f171c0728425c2081e06c44d65)' into 'dev (a59903a https://github.com/switchonproject/cids-custom-switchon-server/commit/a59903aece4df502016ad3b0fef70b64517214ec)' -- Build 37 https://ci.cismet.de/job/cids-custom-switchon-server/37/
— Reply to this email directly or view it on GitHub https://github.com/switchonproject/cids-custom-switchon-server/issues/7#issuecomment-77194431 .
Esa Falkenroth mobile: 070-666-14-14 (intl +46706661414) work: 011-4958298 (intl +46114958298) skype: Esa.Falkenroth email: nospam@falkenroth.se (for business mail) email: esa@falkenroth.se (for private mail)
Queries on the View _pycswview created for pyCSW are very slow on some machines. A
select * from pycsw_view
(> 7.000 rows) takesThe Postgres 9.3/PostGis 2.0 view creation statements are sightly different than the Postgres 8.4/PostGis 1.5 statements since they use new Postgres 9 functions and populate an an additional pyCSW column (type) with data. This could explain the difference between the two deltares servers.
Possible Causes
Implemented Workarounds
The differences after and before the optimisations are negligible. Querying the materialized view on the VM is ~ 5 sec faster than querying the ordinary view!
Other observations Postgres seems to utilize only one CPU, so the # of CPU Cores of the VM is not the limiting factor. The VM is also configured to consume 100% of the assigned cores. There could be an issue with network bandwidth:
But also queries executed within the VM OS are very slow. Another observation is, that not only queries on views, but also queries on object tables are very slow. A
select * from resource
(~7.000 results, ~20MB) takes > 5 sec within the VM!Conclusions: