1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
|
<!-- Converted by db4-upgrade version 1.1 -->
<section xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://docbook.org/ns/docbook" version="5.0" xml:id="database_tuning_configuration">
<title>Performance Tuning</title>
<para>Tuning for PostGIS performance is much like tuning for any PostgreSQL workload.
The only additional consideration is that geometries and rasters are usually large,
so memory-related optimizations generally have more of an impact on PostGIS than other types of PostgreSQL queries.</para>
<para>For general details about optimizing PostgreSQL, refer to <link xlink:href="https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server">Tuning your PostgreSQL Server</link>.</para>
<para>For PostgreSQL 9.4+ configuration can be set at the server level without touching <code>postgresql.conf</code> or <code>postgresql.auto.conf</code>
by using the <code>ALTER SYSTEM</code> command.</para>
<programlisting>ALTER SYSTEM SET work_mem = '256MB';
-- this forces non-startup configs to take effect for new connections
SELECT pg_reload_conf();
-- show current setting value
-- use SHOW ALL to see all settings
SHOW work_mem;</programlisting>
<para>In addition to the Postgres settings, PostGIS has some custom settings which are listed in <xref linkend="PostGIS_GUC"/>.</para>
<section>
<title>Startup</title>
<para>
These settings are configured in <code>postgresql.conf</code>:
</para>
<para>
<link xlink:href="http://www.postgresql.org/docs/current/static/runtime-config-query.html#GUC-CONSTRAINT-EXCLUSION">constraint_exclusion</link>
</para>
<itemizedlist>
<listitem>
<para>
Default: partition
</para>
</listitem>
<listitem>
<para>
This is generally used for table partitioning. The default for this is set to "partition" which is ideal for PostgreSQL 8.4 and above since
it will force the planner to only analyze tables for constraint consideration if they are in an inherited hierarchy
and not pay the planner penalty otherwise.
</para>
</listitem>
</itemizedlist>
<para>
<link xlink:href="http://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-SHARED-BUFFERS">shared_buffers</link>
</para>
<itemizedlist>
<listitem>
<para>
Default: ~128MB in PostgreSQL 9.6
</para>
</listitem>
<listitem>
<para>
Set to about 25% to 40% of available RAM. On windows you may not be able to set as high.
</para>
</listitem>
</itemizedlist>
<para>
<link xlink:href="https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAX-WORKER-PROCESSES">max_worker_processes</link>
This setting is only available for PostgreSQL 9.4+. For PostgreSQL 9.6+ this setting has additional importance in that it controls the
max number of processes you can have for parallel queries.
</para>
<itemizedlist>
<listitem>
<para>
Default: 8
</para>
</listitem>
<listitem>
<para>
Sets the maximum number of background processes that
the system can support. This parameter can only be set at
server start.
</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Runtime</title>
<para>
<link xlink:href="http://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-WORK-MEM">work_mem</link>
- sets the size of memory used for sort operations and complex queries
</para>
<itemizedlist>
<listitem>
<para>
Default: 1-4MB
</para>
</listitem>
<listitem>
<para>
Adjust up for large dbs, complex queries, lots of RAM
</para>
</listitem>
<listitem>
<para>
Adjust down for many concurrent users or low RAM.
</para>
</listitem>
<listitem>
<para>
If you have lots of RAM and few developers:
<programlisting>SET work_mem TO '256MB';</programlisting>
</para>
</listitem>
</itemizedlist>
<para>
<link xlink:href="http://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM">maintenance_work_mem</link>
- the memory size used for VACUUM, CREATE INDEX, etc.
</para>
<itemizedlist>
<listitem>
<para>
Default: 16-64MB
</para>
</listitem>
<listitem>
<para>
Generally too low - ties up I/O, locks objects while swapping memory
</para>
</listitem>
<listitem>
<para>
Recommend 32MB to 1GB on production servers w/lots of RAM, but depends
on the # of concurrent users. If you have lots of RAM and few developers:
<programlisting>SET maintenance_work_mem TO '1GB';</programlisting>
</para>
</listitem>
</itemizedlist>
<para>
<link xlink:href="https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAX-PARALLEL-WORKERS-PER-GATHER">max_parallel_workers_per_gather</link>
</para>
<para>
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 <code>ST_Intersects</code> 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 <code>max_worker_processes</code> to at least as high as this number.
</para>
<itemizedlist>
<listitem>
<para>
Default: 0
</para>
</listitem>
<listitem>
<para>
Sets the maximum number of workers that can be started
by a single <varname>Gather</varname> node.
Parallel workers are taken from the pool of processes
established by <varname>max_worker_processes</varname>.
Note that the requested number of workers may not
actually be available at run time. If this occurs, the
plan will run with fewer workers than expected, which may
be inefficient. Setting this value to 0, which is the
default, disables parallel query execution.
</para>
</listitem>
</itemizedlist>
</section>
</section>
|
