1# SOME DESCRIPTIVE TITLE.
2#
3# Translators:
4# Tommaso Di Bucchianico, 2013
5msgid ""
6msgstr ""
7"Project-Id-Version: PostGIS\n"
8"Report-Msgid-Bugs-To: https://bugs.kde.org\n"
9"POT-Creation-Date: 2021-09-11 01:55+0000\n"
10"PO-Revision-Date: 2013-11-30 05:55+0000\n"
11"Last-Translator: Tommaso Di Bucchianico\n"
12"Language-Team: Italian (Italy) (http://www.transifex.com/projects/p/"
13"postgis-1/language/it_IT/)\n"
14"Language: it_IT\n"
15"MIME-Version: 1.0\n"
16"Content-Type: text/plain; charset=UTF-8\n"
17"Content-Transfer-Encoding: 8bit\n"
18"Plural-Forms: nplurals=2; plural=(n != 1);\n"
19
20#. Tag: title
21#: performance_tips.xml:3
22#, fuzzy, no-c-format
23msgid "Performance Tips"
24msgstr "Consigli per migliori prestazioni"
25
26#. Tag: title
27#: performance_tips.xml:6
28#, no-c-format
29msgid "Small tables of large geometries"
30msgstr "Piccole tabelle contenenti geometrie di grandi dimensioni"
31
32#. Tag: title
33#: performance_tips.xml:9
34#, no-c-format
35msgid "Problem description"
36msgstr "Descrizione del problema"
37
38#. Tag: para
39#: performance_tips.xml:11
40#, fuzzy, no-c-format
41msgid ""
42"Current PostgreSQL versions (including 9.6) suffer from a query optimizer "
43"weakness regarding TOAST tables. TOAST tables are a kind of \"extension room"
44"\" used to store large (in the sense of data size) values that do not fit "
45"into normal data pages (like long texts, images or complex geometries with "
46"lots of vertices), see <ulink url=\"http://www.postgresql.org/docs/current/"
47"static/storage-toast.html\">the PostgreSQL Documentation for TOAST</ulink> "
48"for more information)."
49msgstr ""
50"Le attuali versioni di PostgreSQL (compresa la versione 8.0) sono affette da "
51"un difetto del query optimizer riguardante le tabelle TOAST. Le tabelle "
52"TOAST sono una sorta di \"spazio aggiuntivo\" usato per memorizzare valori "
53"di grandi dimensioni (nel senso di dimensioni dei dati) che non possono "
54"essere salvati in normali pagine (per esempio lunghi testi, immagini o "
55"geometrie con molti vertici). Vedi <ulink url=\"http://www.postgresql.org/"
56"docs/current/static/storage-toast.html\">la  documentazione PostgreSQL sulle "
57"tabelle TOAST</ulink> per maggiori informazioni)."
58
59#. Tag: para
60#: performance_tips.xml:19
61#, fuzzy, no-c-format
62msgid ""
63"The problem appears if you happen to have a table with rather large "
64"geometries, but not too many rows of them (like a table containing the "
65"boundaries of all European countries in high resolution). Then the table "
66"itself is small, but it uses lots of TOAST space. In our example case, the "
67"table itself had about 80 rows and used only 3 data pages, but the TOAST "
68"table used 8225 pages."
69msgstr ""
70"Il problema si presenta nel caso di tabelle contenenti geometrie di grandi "
71"dimensioni ma poche righe (per esempio una tabella contenente i confini di "
72"tutti gli stati europei ad alta risoluzione). In questo caso infatti la "
73"tabella in se è di piccole dimensioni ma usa molto spazio TOAST. Nel nostro "
74"esempio la tabella conteneva circa 80 righe e utilizzava solo 3 pagine di "
75"dati, ma la tabella TOAST ne utilizzava 8225."
76
77#. Tag: para
78#: performance_tips.xml:26
79#, fuzzy, no-c-format
80msgid ""
81"Now issue a query where you use the geometry operator &amp;&amp; to search "
82"for a bounding box that matches only very few of those rows. Now the query "
83"optimizer sees that the table has only 3 pages and 80 rows. It estimates "
84"that a sequential scan on such a small table is much faster than using an "
85"index. And so it decides to ignore the GIST index. Usually, this estimation "
86"is correct. But in our case, the &amp;&amp; operator has to fetch every "
87"geometry from disk to compare the bounding boxes, thus reading all TOAST "
88"pages, too."
89msgstr ""
90"Ora si lanci una query che usi l'operatore  &amp;&amp; e che [MATCHES] solo "
91"poche righe. Il "
92
93#. Tag: para
94#: performance_tips.xml:35
95#, fuzzy, no-c-format
96msgid ""
97"To see whether your suffer from this issue, use the \"EXPLAIN ANALYZE\" "
98"postgresql command. For more information and the technical details, you can "
99"read the thread on the PostgreSQL performance mailing list: <ulink url="
100"\"http://archives.postgresql.org/pgsql-performance/2005-02/msg00030.php"
101"\">http://archives.postgresql.org/pgsql-performance/2005-02/msg00030.php</"
102"ulink>"
103msgstr ""
104"Per controllare se i propri dati sono interessati da questo bug, si può "
105"usare il comando PostgreSQL \"EXPLAIN ANALYZE\". Per maggiori informazioni e "
106"dettagli tecnici consultare il corrispondente thread sulla mailing list di "
107"PostgreSQL: http://archives.postgresql.org/pgsql-performance/2005-02/"
108"msg00030.php"
109
110#. Tag: para
111#: performance_tips.xml:41
112#, no-c-format
113msgid ""
114"and newer thread on PostGIS <ulink url=\"https://lists.osgeo.org/pipermail/"
115"postgis-devel/2017-June/026209.html\">https://lists.osgeo.org/pipermail/"
116"postgis-devel/2017-June/026209.html</ulink>"
117msgstr ""
118
119#. Tag: title
120#: performance_tips.xml:45
121#, no-c-format
122msgid "Workarounds"
123msgstr "Possibili soluzioni"
124
125#. Tag: para
126#: performance_tips.xml:47
127#, no-c-format
128msgid ""
129"The PostgreSQL people are trying to solve this issue by making the query "
130"estimation TOAST-aware. For now, here are two workarounds:"
131msgstr ""
132"Gli sviluppatori di PostgreSQL stanno cercando di risolvere il problema "
133"rendendo la valutazione della query indipendente dalla tabella TOAST. Per "
134"ora ci sono due possibili soluzioni alternative:"
135
136#. Tag: para
137#: performance_tips.xml:50
138#, no-c-format
139msgid ""
140"The first workaround is to force the query planner to use the index. Send "
141"\"SET enable_seqscan TO off;\" to the server before issuing the query. This "
142"basically forces the query planner to avoid sequential scans whenever "
143"possible. So it uses the GIST index as usual. But this flag has to be set on "
144"every connection, and it causes the query planner to make misestimations in "
145"other cases, so you should \"SET enable_seqscan TO on;\" after the query."
146msgstr ""
147"La è forzare il query planner ad usare l'indice spaziale usando il comando "
148"\"SET enable_seqscan TO off;\" prima di lanciare la query. Questo comando "
149"impedisce al query planner di usare lo scan sequenziale della tabella se "
150"possibile e lo forza quindi ad usare l'indice GIST. Tuttavia il comando deve "
151"essere lanciato ad ogni connessione e, per evitare di confondere il query "
152"planner in altri casi,  il parametro deve essere resettato dopo l'esecuzione "
153"della query interessata con il comando \"SET enable_seqscan TO on;\" ."
154
155#. Tag: para
156#: performance_tips.xml:58
157#, no-c-format
158msgid ""
159"The second workaround is to make the sequential scan as fast as the query "
160"planner thinks. This can be achieved by creating an additional column that "
161"\"caches\" the bbox, and matching against this. In our example, the commands "
162"are like:"
163msgstr ""
164"Il secondo metodo è rendere lo scan sequenziale così veloce come il query "
165"planner si aspetta che sia. Questo può essere raggiunto aggiungendo una "
166"colonna addizionale in cui salvare la bounding box di ogni geometria. Nel "
167"nostro esempio i comandi sarebbero:"
168
169#. Tag: programlisting
170#: performance_tips.xml:63
171#, fuzzy, no-c-format
172msgid ""
173"SELECT "
174"AddGeometryColumn('myschema','mytable','bbox','4326','GEOMETRY','2');\n"
175"UPDATE mytable SET bbox = ST_Envelope(ST_Force2D(geom));"
176msgstr ""
177"SELECT "
178"AddGeometryColumn('myschema','mytable','bbox','4326','GEOMETRY','2');\n"
179"UPDATE mytable SET bbox = ST_Envelope(ST_Force_2d(the_geom));"
180
181#. Tag: para
182#: performance_tips.xml:65
183#, no-c-format
184msgid ""
185"Now change your query to use the &amp;&amp; operator against bbox instead of "
186"geom_column, like:"
187msgstr ""
188"Ora la query deve essere modificata in modo da usare l'operatore &amp;&amp; "
189"con la colonna bbox piuttosto che con la colonna geom_column:"
190
191#. Tag: programlisting
192#: performance_tips.xml:68
193#, fuzzy, no-c-format
194msgid ""
195"SELECT geom_column\n"
196"FROM mytable\n"
197"WHERE bbox &amp;&amp; ST_SetSRID('BOX3D(0 0,1 1)'::box3d,4326);"
198msgstr ""
199"SELECT geom_column\n"
200"FROM mytable\n"
201"WHERE bbox &amp;&amp; ST_SetSRID('BOX3D(0 0,1 1)'::box3d,4326);"
202
203#. Tag: para
204#: performance_tips.xml:70
205#, no-c-format
206msgid ""
207"Of course, if you change or add rows to mytable, you have to keep the bbox "
208"\"in sync\". The most transparent way to do this would be triggers, but you "
209"also can modify your application to keep the bbox column current or run the "
210"UPDATE query above after every modification."
211msgstr ""
212"Ovviamente la colonna bbox deve essere mantenuta attuale quando si "
213"modificano o si aggiungono geometrie. La via più semplice per fare questo "
214"sarebbe con un trigger, oppure l'applicazione può essere modificata in modo "
215"da attualizzare anche la colonna bbox oppure si può lanciare l'UPDATE "
216"precedente dopo ogni modifica."
217
218#. Tag: title
219#: performance_tips.xml:79
220#, no-c-format
221msgid "CLUSTERing on geometry indices"
222msgstr "CLUSTERing di indici geometrici"
223
224#. Tag: para
225#: performance_tips.xml:81
226#, no-c-format
227msgid ""
228"For tables that are mostly read-only, and where a single index is used for "
229"the majority of queries, PostgreSQL offers the CLUSTER command. This command "
230"physically reorders all the data rows in the same order as the index "
231"criteria, yielding two performance advantages: First, for index range scans, "
232"the number of seeks on the data table is drastically reduced. Second, if "
233"your working set concentrates to some small intervals on the indices, you "
234"have a more efficient caching because the data rows are spread along fewer "
235"data pages. (Feel invited to read the CLUSTER command documentation from the "
236"PostgreSQL manual at this point.)"
237msgstr ""
238"Per tabelle che vengono per lo più solo lette, e dove un singolo indice è "
239"usato dalla maggior parte delle query, PostgreSQL offre il comando CLUSTER. "
240"Questo comando riordina fisicamente le righe in modo che l'ordine "
241"corrisponda a quello dell'indice. Con questo metodo si migliorano le "
242"prestazioni per due motivi: primo, il numero delle ricerche nella tabella "
243"dei dati è ridotto drasticamente. Secondo, se i dati interessati dalla query "
244"sono concentrati in un piccolo intervallo sull'indice, il processo di "
245"mettere in cache sarà più efficiente perché le righe saranno distribuite "
246"all'interno di poche pagine. (si invita a leggere la documentazione di "
247"PostgreSQL riguardante il comando CLUSTER)."
248
249#. Tag: para
250#: performance_tips.xml:91
251#, no-c-format
252msgid ""
253"However, currently PostgreSQL does not allow clustering on PostGIS GIST "
254"indices because GIST indices simply ignores NULL values, you get an error "
255"message like:"
256msgstr ""
257"Attualmente però, PostgreSQL non permette di usare il clustering con indici "
258"GIST, perché gli indici GIST ignorano i valori nulli:"
259
260#. Tag: programlisting
261#: performance_tips.xml:95
262#, fuzzy, no-c-format
263msgid ""
264"lwgeom=# CLUSTER my_geom_index ON my_table;\n"
265"ERROR: cannot cluster when index access method does not handle null values\n"
266"HINT: You may be able to work around this by marking column \"geom\" NOT "
267"NULL."
268msgstr ""
269"lwgeom=# CLUSTER my_geom_index ON my_table;\n"
270"ERROR: cannot cluster when index access method does not handle null values\n"
271"HINT: You may be able to work around this by marking column \"the_geom\" NOT "
272"NULL."
273
274#. Tag: para
275#: performance_tips.xml:97
276#, no-c-format
277msgid ""
278"As the HINT message tells you, one can work around this deficiency by adding "
279"a \"not null\" constraint to the table:"
280msgstr ""
281"Come suggerito dal messaggio di errore, è possibile aggirare il problema "
282"aggiungendo un vincolo \"NOT NULL\" alla tabella:"
283
284#. Tag: programlisting
285#: performance_tips.xml:100
286#, fuzzy, no-c-format
287msgid ""
288"lwgeom=# ALTER TABLE my_table ALTER COLUMN geom SET not null;\n"
289"ALTER TABLE"
290msgstr ""
291"lwgeom=# ALTER TABLE my_table ALTER COLUMN the_geom SET not null; \n"
292"ALTER TABLE"
293
294#. Tag: para
295#: performance_tips.xml:102
296#, no-c-format
297msgid ""
298"Of course, this will not work if you in fact need NULL values in your "
299"geometry column. Additionally, you must use the above method to add the "
300"constraint, using a CHECK constraint like \"ALTER TABLE blubb ADD CHECK "
301"(geometry is not null);\" will not work."
302msgstr ""
303"Ovviamente questo non funzionerà se la colonna the_geom già contiene valori "
304"nulli. Inoltre il vincolo dev'essere definito usando il comando precedente. "
305"Usare un vincolo CHECK del tipo \"ALTER TABLE blubb ADD CHECK (geometry is "
306"not null);\" non funzionerà."
307
308#. Tag: title
309#: performance_tips.xml:109
310#, no-c-format
311msgid "Avoiding dimension conversion"
312msgstr "Evitare la conversione della dimensione"
313
314#. Tag: para
315#: performance_tips.xml:111
316#, fuzzy, no-c-format
317msgid ""
318"Sometimes, you happen to have 3D or 4D data in your table, but always access "
319"it using OpenGIS compliant ST_AsText() or ST_AsBinary() functions that only "
320"output 2D geometries. They do this by internally calling the ST_Force2D() "
321"function, which introduces a significant overhead for large geometries. To "
322"avoid this overhead, it may be feasible to pre-drop those additional "
323"dimensions once and forever:"
324msgstr ""
325"A volte può accadere di avere dati in 3D o 4D, ma di accederli sempre usando "
326"funzioni che danno in output solo geometrie 2D come ST_AsText() oppure "
327"ST_AsBinary(). Queste funzioni processano internamente le geometrie "
328"eseguendo ST_Force2D()  e questo può risultare in un peggioramento delle "
329"prestazioni significativo nel caso di geometrie di grandi dimensioni. Per "
330"evitare questo problema è consigliabile eliminare le dimensioni non "
331"utilizzate una volte e per sempre:"
332
333#. Tag: programlisting
334#: performance_tips.xml:118
335#, fuzzy, no-c-format
336msgid ""
337"UPDATE mytable SET geom = ST_Force2D(geom);\n"
338"VACUUM FULL ANALYZE mytable;"
339msgstr ""
340"UPDATE mytable SET the_geom = ST_Force_2d(the_geom); \n"
341"VACUUM FULL ANALYZE mytable;"
342
343#. Tag: para
344#: performance_tips.xml:120
345#, no-c-format
346msgid ""
347"Note that if you added your geometry column using AddGeometryColumn() "
348"there'll be a constraint on geometry dimension. To bypass it you will need "
349"to drop the constraint. Remember to update the entry in the geometry_columns "
350"table and recreate the constraint afterwards."
351msgstr ""
352"Se la colonna di tipo geometry è stata aggiunta usando la funzione "
353"AddGeometryColumn(), verrà creato anche un vincolo dimensionale sulla "
354"geometria. Per aggirare il vincolo sarà necessario cancellarlo. Ricorda di "
355"attualizzare il record nella tabella geometry_columns e di ricreare il "
356"vincolo successivamente. "
357
358#. Tag: para
359#: performance_tips.xml:126
360#, fuzzy, no-c-format
361msgid ""
362"In case of large tables, it may be wise to divide this UPDATE into smaller "
363"portions by constraining the UPDATE to a part of the table via a WHERE "
364"clause and your primary key or another feasible criteria, and running a "
365"simple \"VACUUM;\" between your UPDATEs. This drastically reduces the need "
366"for temporary disk space. Additionally, if you have mixed dimension "
367"geometries, restricting the UPDATE by \"WHERE dimension(geom)&gt;2\" skips "
368"re-writing of geometries that already are in 2D."
369msgstr ""
370"Nel caso di grandi tabelle può essere sensato dividere l'UPDATE in porzioni "
371"più piccole, usando la clausola WHERE con la chiave primaria o un altro "
372"criterio flessibile per attualizzare solo una parte della tabella , ed "
373"eseguendo un semplice \"VACUUM;\" tra gli UPDATE. Questo accorgimento "
374"ridurrà drasticamente il bisogno lo spazio temporaneo sul disco. Inoltre, se "
375"la colonna geometrica contiene geometrie con diverse dimensioni, si può "
376"limitare l'UPDATE con \"WHERE dimension(the_geom)&gt;2\", evitando così di "
377"riscrivere le geometrie che sono già in 2D."
378
379#~ msgid "Tuning your configuration"
380#~ msgstr "Mettere a punto la configurazione"
381
382#~ msgid "Startup"
383#~ msgstr "Startup"
384
385#~ msgid "These settings are configured in postgresql.conf:"
386#~ msgstr "Queste impostazioni sono definite in postgresql.conf:"
387
388#~ msgid "constraint_exclusion"
389#~ msgstr "constraint_exclusion"
390
391#, fuzzy
392#~ msgid "Default: partition"
393#~ msgstr "Default: 1MB"
394
395#, fuzzy
396#~ msgid ""
397#~ "This is generally used for table partitioning. The default for this is "
398#~ "set to \"partition\" which is ideal for PostgreSQL 8.4 and above since it "
399#~ "will force the planner to only analyze tables for constraint "
400#~ "consideration if they are in an inherited hierarchy and not pay the "
401#~ "planner penalty otherwise."
402#~ msgstr ""
403#~ "Generalmente usato per il partizionamento delle tabelle. Con versioni di "
404#~ "PostgreSQL inferiori alla 8.4 impostare il parametro su \"on\" per "
405#~ "permettere al query planner di ottimizzare secondo necessità. Da "
406#~ "PostgreSQL 8.4, il valore di default è \"partition\", ideale per versioni "
407#~ "8.4 e superiori perché forza il query planner ad analizzare i vincoli "
408#~ "delle tabelle solo  se queste sono in una gerarchia di ereditarietà e non "
409#~ "essere penalizzate dal planner in caso contrario."
410
411#~ msgid "shared_buffers"
412#~ msgstr "shared_buffers"
413
414#, fuzzy
415#~ msgid ""
416#~ "<ulink url=\"https://www.postgresql.org/docs/current/static/runtime-"
417#~ "config-resource.html#GUC-MAX-WORKER-PROCESSES\">max_worker_processes</"
418#~ "ulink> This setting is only available for PostgreSQL 9.4+. For PostgreSQL "
419#~ "9.6+ this setting has additional importance in that it controls the max "
420#~ "number of processes you can have for parallel queries."
421#~ msgstr ""
422#~ "<ulink url=\"http://www.postgresql.org/docs/current/static/runtime-config-"
423#~ "resource.html#GUC-WORK-MEM\">work_mem</ulink> (memoria usata per "
424#~ "operazioni di ordinamento e query complesse)"
425
426#, fuzzy
427#~ msgid "Default: 8"
428#~ msgstr "Default: 1MB"
429
430#~ msgid "Runtime"
431#~ msgstr "Runtime"
432
433#~ msgid ""
434#~ "<ulink url=\"http://www.postgresql.org/docs/current/static/runtime-config-"
435#~ "resource.html#GUC-WORK-MEM\">work_mem</ulink> (the memory used for sort "
436#~ "operations and complex queries)"
437#~ msgstr ""
438#~ "<ulink url=\"http://www.postgresql.org/docs/current/static/runtime-config-"
439#~ "resource.html#GUC-WORK-MEM\">work_mem</ulink> (memoria usata per "
440#~ "operazioni di ordinamento e query complesse)"
441
442#, fuzzy
443#~ msgid "Default: 1-4MB"
444#~ msgstr "Default: 1MB"
445
446#~ msgid "Adjust up for large dbs, complex queries, lots of RAM"
447#~ msgstr ""
448#~ "Aumentare il valore per grandi database, query complesse, abbondanza di "
449#~ "RAM"
450
451#~ msgid "Adjust down for many concurrent users or low RAM."
452#~ msgstr ""
453#~ "Diminuire il valore nel caso di molti utenti concorrenti oppure "
454#~ "disponibilità di RAM ridotta"
455
456#~ msgid "If you have lots of RAM and few developers:"
457#~ msgstr "Nel caso di molta RAM e pochi programmatori:"
458
459#, fuzzy
460#~ msgid "SET work_mem TO '256MB';"
461#~ msgstr "SET work_mem TO 1200000;"
462
463#~ msgid ""
464#~ "<ulink url=\"http://www.postgresql.org/docs/current/static/runtime-config-"
465#~ "resource.html#GUC-MAINTENANCE-WORK-MEM\">maintenance_work_mem</ulink> "
466#~ "(used for VACUUM, CREATE INDEX, etc.)"
467#~ msgstr ""
468#~ "<ulink url=\"http://www.postgresql.org/docs/current/static/runtime-config-"
469#~ "resource.html#GUC-MAINTENANCE-WORK-MEM\">maintenance_work_mem</ulink> "
470#~ "(usato per VACUUM, CREATE INDEX, etc.)"
471
472#, fuzzy
473#~ msgid "Default: 16-64MB"
474#~ msgstr "Default: 16MB"
475
476#~ msgid "Generally too low - ties up I/O, locks objects while swapping memory"
477#~ msgstr ""
478#~ "Generalmente troppo basso. Tiene occupati i processi Input/Output e "
479#~ "blocca oggetti quando viene impegnata la memoria swap."
480
481#, fuzzy
482#~ msgid ""
483#~ "Recommend 32MB to 1GB on production servers w/lots of RAM, but depends on "
484#~ "the # of concurrent users. If you have lots of RAM and few developers:"
485#~ msgstr ""
486#~ "Si raccomandano 32MB oppure 256MB su server di produzione con molta RAM, "
487#~ "ma dipende dal numero di utenti concorrenti. Nel caso di molta RAM e "
488#~ "pochi sviluppatori:"
489
490#, fuzzy
491#~ msgid "SET maintenance_work_mem TO '1GB';"
492#~ msgstr "SET maintainence_work_mem TO 1200000;"
493
494#, fuzzy
495#~ msgid "Default: 0"
496#~ msgstr "Default: 1MB"
497
498#~ msgid "Default: ~32MB"
499#~ msgstr "Default: ~32MB"
500
501#~ msgid "Set to about 1/3 to 3/4 of available RAM"
502#~ msgstr "Impostare da 1/3 a 3/4 della RAM disponibile."
503
504#~ msgid ""
505#~ "These tips are taken from Kevin Neufeld's presentation \"Tips for the "
506#~ "PostGIS Power User\" at the FOSS4G 2007 conference. Depending on your use "
507#~ "of PostGIS (for example, static data and complex analysis vs frequently "
508#~ "updated data and lots of users) these changes can provide significant "
509#~ "speedups to your queries."
510#~ msgstr ""
511#~ "Questi consigli sono tratti dalla presentazione di Kevin Neufeld  \"Tips "
512#~ "for the PostGIS Power User\" alla conferenza FOSS4G 2007. A seconda del "
513#~ "contesto in cui viene usato PostGIS (per esempio dati statici e analisi "
514#~ "complesse piuttosto che update frequenti e numerosi utenti) questi "
515#~ "cambiamenti possono significare un significativo aumento della velocità "
516#~ "delle query."
517
518#~ msgid ""
519#~ "For a more tips (and better formatting), the original presentation is at "
520#~ "<ulink url=\"http://2007.foss4g.org/presentations/view.php?"
521#~ "abstract_id=117\"> http://2007.foss4g.org/presentations/view.php?"
522#~ "abstract_id=117</ulink>."
523#~ msgstr ""
524#~ "Per più consigli (e una formattazione migliore) la presentazione "
525#~ "originale è consultabile a <ulink url=\"http://2007.foss4g.org/"
526#~ "presentations/view.php?abstract_id=117\"> http://2007.foss4g.org/"
527#~ "presentations/view.php?abstract_id=117</ulink>."
528
529#~ msgid "checkpoint_segments"
530#~ msgstr "checkpoint_segments"
531
532#~ msgid ""
533#~ "Maximum number of log file segments between automatic WAL checkpoints "
534#~ "(each segment is normally 16MB); default is 3"
535#~ msgstr ""
536#~ "Numero massimo di segmenti del log file tra checkpoint WAL (ogni segmento "
537#~ "è normalmente 16MB); l'impostazione predefinita è 3."
538
539#~ msgid ""
540#~ "Set to at least 10 or 30 for databases with heavy write activity, or more "
541#~ "for large database loads. Another article on the topic worth reading "
542#~ "<ulink url=\"http://www.westnet.com/~gsmith/content/postgresql/chkp-"
543#~ "bgw-83.htm\">Greg Smith: Checkpoint and Background writer</ulink>"
544#~ msgstr ""
545#~ "Impostare almeno su 10 o 30 per database con intensa attività di "
546#~ "scrittura, o più quando si importa nel database grandi quantità di dati. "
547#~ "Un altro articolo da leggere sull'argomento è <ulink url=\"http://www."
548#~ "westnet.com/~gsmith/content/postgresql/chkp-bgw-83.htm\">Greg Smith: "
549#~ "Checkpoint and Background writer</ulink> "
550
551#~ msgid "Possibly store the xlog on a separate disk device"
552#~ msgstr "Se possibile, salvare il xlog su un disco separato"
553
554#~ msgid ""
555#~ "Default: off (prior to PostgreSQL 8.4 and for PostgreSQL 8.4+ is set to "
556#~ "partition)"
557#~ msgstr ""
558#~ "Il valore di default è \"off\" per versioni inferiori alla 8.4 e "
559#~ "\"partition\" a partire dalla 8.4()"
560