Overview

Project website postgis.net
Translation process
  • Translations can be made directly.
  • Translation suggestions can be made.
  • Any authenticated user can contribute.
  • The translation uses bilingual files.
Source code repository https://git.osgeo.org/gitea/postgis/postgis.git
Repository branch stable-3.2
Last remote commit Push to 3.2.6dev milestone 6e2c5206d
Regina Obe authored 2 days ago
Weblate repository https://weblate.osgeo.org/git/postgis_branch_32/postgis/
File mask doc/po/*/performance_tips.xml.po
Translation file Download doc/po/fr/performance_tips.xml.po
Last change None
Last author None

String statistics

Strings percent Hosted strings Words percent Hosted words Characters percent Hosted characters
Total 28 935 6,108
Translated 53% 15 48% 452 44% 2,713
Needs editing 39% 11 44% 415 45% 2,808
Read-only 0% 0 0% 0 0% 0
Failing checks 50% 14 43% 411 45% 2,806
Strings with suggestions 46% 13 51% 483 55% 3,395
Untranslated strings 7% 2 7% 68 9% 587
Last 12 months Previous

Activity in last 12 months

0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 13 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 30 changes 0 changes
Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May

Quick numbers

935
Hosted words
28
Hosted strings
53%
Translated
0
Contributors
and previous 30 days

Trends of last 30 days

—
Hosted words
—
—
Hosted strings
—
—
Translated
—
—
Contributors
—
User avatar anonymous

Suggestion added

postgis_branch_32 / performance_tips — French

In case of large tables, it may be wise to divide this UPDATE into smaller portions by constraining the UPDATE to a part of the table via a WHERE clause and your primary key or another feasible criteria, and running a simple "VACUUM;" between your UPDATEs. This drastically reduces the need for temporary disk space. Additionally, if you have mixed dimension geometries, restricting the UPDATE by "WHERE dimension(geom)>2" skips re-writing of geometries that already are in 2D.
En cas de grandes tables, il peut être judicieux de diviser cette mise à jour en petites portions en restreignant l'UPDATE à une partie de la table via une clause WHERE et votre clé primaire ou d'un autre critère, et exécutant un simple «VACUUM» ; entre votre mises à jour. Cela réduit considérablement le besoin d'espace disque temporaire. En outre, si vous avez des données géométriques de dimension mixte, restreindre la mise à jour en "WHERE dimension(the_geom)&gt ;2" saute la ré-écriture des géométries qui sont déjà en 2D.
4 months ago
User avatar anonymous

Suggestion added

postgis_branch_32 / performance_tips — French

UPDATE mytable SET geom = ST_Force2D(geom);
VACUUM FULL ANALYZE mytable;
UPDATE mytable SET the_geom = ST_Force2D(the_geom) ;
VACUUM FULL ANALYZE mytable ;
4 months ago
User avatar anonymous

Suggestion added

postgis_branch_32 / performance_tips — French

Sometimes, you happen to have 3D or 4D data in your table, but always access it using OpenGIS compliant ST_AsText() or ST_AsBinary() functions that only output 2D geometries. They do this by internally calling the ST_Force2D() function, which introduces a significant overhead for large geometries. To avoid this overhead, it may be feasible to pre-drop those additional dimensions once and forever:
Il arrive parfois que vous ayez des données 3D ou 4D dans votre table, mais que vous y accédiez toujours à l'aide des fonctions ST_AsText() ou ST_AsBinary() conformes à OpenGIS qui ne produisent que des géométries 2D. Pour ce faire, elles appellent en interne la fonction ST_Force2D(), qui introduit une surcharge importante pour les géométries de grande taille. Pour éviter cette surcharge, il peut être possible de pré-déposer ces dimensions supplémentaires une fois pour toutes :
4 months ago
User avatar anonymous

Suggestion added

postgis_branch_32 / performance_tips — French

lwgeom=# ALTER TABLE my_table ALTER COLUMN geom SET not null;
ALTER TABLE
lwgeom=# ALTER TABLE my_table ALTER COLUMN the_geom SET not null ;
ALTER TABLE
4 months ago
User avatar anonymous

Suggestion added

postgis_branch_32 / performance_tips — French

lwgeom=# CLUSTER my_geom_index ON my_table;
ERROR: cannot cluster when index access method does not handle null values
HINT: You may be able to work around this by marking column "geom" NOT NULL.
lwgeom=# CLUSTER my_geom_index ON my_table ;
ERROR : cannot cluster when index access method does not handle null values
HINT : You may be able to work around this by marking column "the_geom" NOT NULL.
4 months ago
User avatar anonymous

Suggestion added

postgis_branch_32 / performance_tips — French

SELECT geom_column
FROM mytable
WHERE bbox && ST_SetSRID('BOX3D(0 0,1 1)'::box3d,4326);
SELECT geom_column
FROM mytable
WHERE bbox &amp ;&amp ; ST_SetSRID('BOX3D(0 0,1 1)' ::box3d,4326) ;
4 months ago
User avatar anonymous

Suggestion added

postgis_branch_32 / performance_tips — French

SELECT AddGeometryColumn('myschema','mytable','bbox','4326','GEOMETRY','2');
UPDATE mytable SET bbox = ST_Envelope(ST_Force2D(geom));
SELECT AddGeometryColumn('myschema','mytable','bbox','4326','GEOMETRY','2') ;
UPDATE mytable SET bbox = ST_Envelope(ST_Force2D(the_geom)) ;
4 months ago
User avatar anonymous

Suggestion added

postgis_branch_32 / performance_tips — French

and newer thread on PostGIS <ulink url="https://lists.osgeo.org/pipermail/postgis-devel/2017-June/026209.html">https://lists.osgeo.org/pipermail/postgis-devel/2017-June/026209.html</ulink>
et un fil d'actualités plus récent sur PostGIS <ulink url="https://lists.osgeo.org/pipermail/postgis-devel/2017-June/026209.html">https://lists.osgeo.org/pipermail/postgis-devel/2017-June/026209.html</ulink>
4 months ago
User avatar anonymous

Suggestion added

postgis_branch_32 / performance_tips — French

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 PostgreSQL performance mailing list: <ulink url="http://archives.postgresql.org/pgsql-performance/2005-02/msg00030.php">http://archives.postgresql.org/pgsql-performance/2005-02/msg00030.php</ulink>
Pour voir si votreus souffrentz de ce boguproblème, utilisez la commande postgresql "EXPLAIN ANALYZE" de postgresql. Pour plus d'informations et les détails techniques, vous pouvez lire le fil de discussion sur la liste de diffusion dsur les performances de pPostgres: SQL : <ulink url="http ://archives.postgresql.org/pgsql-performance/2005-02/msg00030.php">http ://archives.postgresql.org/pgsql-performance/2005-02/msg00030.php</ulink>
4 months ago
User avatar anonymous

Suggestion added

postgis_branch_32 / performance_tips — French

Now issue a query where you use the geometry operator &amp;&amp; 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. 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 &amp;&amp; operator has to fetch every geometry from disk to compare the bounding boxes, thus reading all TOAST pages, too.
Maintenant émettre une requête en utilisant l'opérateur de géométrie &amp;&amp; pour rechercher une boîte englobante qui correspond que très peu de ces lignes. Maintenant l'optimiseur de requêtes voit que la table n'a que 3 pages et 80 lignes. Il estime qu'une analyse séquentielle sur une telle petite table est beaucoup plus rapide que d'utiliser un index. Et alors il décide d'ignorer l'index GIST. Habituellement, cette estimation est correcte. Mais dans notre cas, l'opérateur &amp;&amp; doit aller chercher chaque géométrie à partir du disque pour comparer les boîtes englobantes, et par conséquent la lecture de toutes les pages TOAST également.
4 months ago
Browse all translation changes