From: Regina Obe Date: Fri, 30 Jun 2017 20:43:48 +0000 (+0000) Subject: Bring performance tips section up to newer versions X-Git-Tag: 2.3.3~3 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=a4c9eee9fb7da5851fb188f16dd6e29a23aeb112;p=postgis Bring performance tips section up to newer versions Closes #3746 for PostGIS 2.3 (branch) git-svn-id: http://svn.osgeo.org/postgis/branches/2.3@15469 b70326c6-7e19-0410-871a-916f4a2858ee --- diff --git a/doc/performance_tips.xml b/doc/performance_tips.xml index adf293134..8832a75b8 100644 --- a/doc/performance_tips.xml +++ b/doc/performance_tips.xml @@ -8,7 +8,7 @@ Problem description - Current PostgreSQL versions (including 8.0) suffer from a query + Current PostgreSQL versions (including 9.6) suffer from a query optimizer weakness regarding TOAST tables. TOAST tables are a kind of "extension room" used to store large (in the sense of data size) values that do not fit into normal data pages (like long texts, images or @@ -17,7 +17,7 @@ information). The problem appears if you happen to have a table with rather - large geometries, but not too much rows of them (like a table containing + large geometries, but not too manyrows of them (like a table containing the boundaries of all European countries in high resolution). Then the table itself is small, but it uses lots of TOAST space. In our example case, the table itself had about 80 rows and used only 3 data pages, but @@ -26,17 +26,19 @@ Now issue a query where you use the geometry operator && to search for a bounding box that matches only very few of those rows. Now the query optimizer sees that the table has only 3 pages and 80 - rows. He estimates that a sequential scan on such a small table is much - faster than using an index. And so he decides to ignore the GIST index. + rows. It estimates that a sequential scan on such a small table is much + faster than using an index. And so it decides to ignore the GIST index. Usually, this estimation is correct. But in our case, the && operator has to fetch every geometry from disk to compare the bounding boxes, thus reading all TOAST pages, too. - To see whether your suffer from this bug, use the "EXPLAIN + To see whether your suffer from this issue, use the "EXPLAIN ANALYZE" postgresql command. For more information and the technical details, you can read the thread on the postgres performance mailing list: - http://archives.postgresql.org/pgsql-performance/2005-02/msg00030.php + http://archives.postgresql.org/pgsql-performance/2005-02/msg00030.php + + and newer thread on PostGIS https://lists.osgeo.org/pipermail/postgis-devel/2017-June/026209.html @@ -146,7 +148,7 @@ VACUUM FULL ANALYZE mytable; geometries and rasters are heavy so memory related optimizations generally have more of an impact on PostGIS than other types of PostgreSQL queries. For general details about optimizing PostgreSQL, refer to Tuning your PostgreSQL Server. - + For PostgreSQL 9.4+ all these can be set at the server level without touching postgresql.conf or postgresql.auto.conf by using the ALTER SYSTEM.. command. ALTER SYSTEM SET work_mem = '256MB'; @@ -191,17 +193,17 @@ SHOW work_mem; - Default: ~32MB + Default: ~128MB in PostgreSQL 9.6 - Set to about 1/3 to 3/4 of available RAM + Set to about 25% to 40% of available RAM. On windows you may not be able to set as high. - - + + max_worker_processes This setting is only available for PostgreSQL 9.4+. For PostgreSQL 9.6+ this setting has additional importance in that it controls the @@ -251,7 +253,7 @@ SHOW work_mem; If you have lots of RAM and few developers: - SET work_mem TO '256MB';; + SET work_mem TO '256MB'; @@ -282,10 +284,10 @@ SHOW work_mem; - + max_parallel_workers_per_gather - This setting is only available for PostgreSQL 9.6+ and will only affect PostGIS 2.3+, since only PostGIS 2.3+ supports parallel queries. + This setting is only available for PostgreSQL 9.6+ and will only affect PostGIS 2.3+, since only PostGIS 2.3+ supports parallel queries. If set to higher than 0, then some queries such as those involving relation functions like ST_Intersects can use multiple processes and can run more than twice as fast when doing so. If you have a lot of processors to spare, you should change the value of this to as many processors as you have. Also make sure to bump up max_worker_processes to at least as high as this number. diff --git a/doc/using_postgis_dataman.xml b/doc/using_postgis_dataman.xml index c9081630b..ef9ffc6af 100644 --- a/doc/using_postgis_dataman.xml +++ b/doc/using_postgis_dataman.xml @@ -90,7 +90,7 @@ geometry = ST_GeometryFromText(text WKT, SRID); SRID information. Examples of the text representations (EWKT) of the extended - spatial objects of the features are as follows. The * ones are new in this version of PostGIS: + spatial objects of the features are as follows. @@ -748,16 +748,17 @@ SELECT AddGeometryColumn( 'roads', 'roads_geom', 0, 'GEOMETRY', 3 ); Manually Registering Geometry Columns in geometry_columns - The AddGeometryColumn() approach creates a geometry column and also registers the new - column in the geometry_columns table. If your software utilizes geometry_columns, then - any geometry columns you need to query by must be registered in this view. + The AddGeometryColumn() approach creates a geometry column of specified type. + This type and dimension are queryable from the geometry_columns view. Starting with PostGIS 2.0, geometry_columns is no longer editable and all geometry columns are autoregistered. - However they may be registered as a generic geometry column if the column was not defined as a specific type during creation. + If your geometry columns were created as generic in a table or view and no constraints applied, they will not have a dimension, type or srid in geometry_columns views, but will still be listed. Two of the cases where this may happen, but you can't use - AddGeometryColumn, is in the case of SQL Views and bulk inserts. For these cases, you can correct the registration in the geometry_columns table - by constraining the column. Note in PostGIS 2.0+ if your column is typmod based, the creation process would register it correctly, so no need to do anything. + AddGeometryColumn, is in the case of SQL Views and bulk inserts. For bulk insert case, you can correct the registration in the geometry_columns table + by constraining the column or doing an alter table. For views, you could expose using a CAST operation. + Note in PostGIS 2.0+ if your column is typmod based, the creation process would register it correctly, so no need to do anything. + Also views that have no spatial function applied to the geometry will register the same as the underlying table geometry column. --Lets say you have a view created like this CREATE VIEW public.vwmytablemercator AS @@ -805,7 +806,7 @@ SELECT populate_geometry_columns('myschema.my_special_pois'::regclass); -- set new optional use_typmod argument to false SELECT populate_geometry_columns('myschema.my_special_pois'::regclass, false); -Although the old-constraint based method is still supported, a constraint-based geomentry column used directly +Although the old-constraint based method is still supported, a constraint-based geometry column used directly in a view, will not register correctly in geometry_columns, as will a typmod one. In this example we define a column using typmod and another using constraints. CREATE TABLE pois_ny(gid SERIAL PRIMARY KEY