Le portail francophone de la géomatique

badol · Mon 21 October 2024 07:36

Bonjour,

J'ai beaucoup de tables en Lambert 93 avec 9 chiffres après la virgule.

J'avais subodoré que réduire cette précision inutile ferait gagner de la place sur le disque, augmenterait un peu la vitesse d'affichage et réduirait le temps des géotraitements.

J'ai questionné chatGPT sur le sujet (qui n'a pas été très bon il faut le reconnaitre) : https://chatgpt.com/share/6714c630-6270 … 8648c01dbe

Je vous livre mes comparaisons entre
- ST_ReducePrecision à 0.01
- ST_SnapToGrid à 0.01
- ST_QuantizeCoordinates à 0

---- Situation initiale (en Lambert93):
DROP TABLE IF EXISTS public.l_bati_agrege_pepci_006_2023;
CREATE TABLE public.l_bati_agrege_pepci_006_2023
(LIKE p_enveloppe_bati_2023.l_bati_agrege_pepci_006_2023 INCLUDING ALL);
ALTER TABLE IF EXISTS public.l_bati_agrege_pepci_006_2023
CLUSTER ON l_bati_agrege_pepci_006_2023_geom_idx;
INSERT INTO public.l_bati_agrege_pepci_006_2023
SELECT * FROM p_enveloppe_bati_2023.l_bati_agrege_pepci_006_2023;
--> Updated Rows 305707
SELECT pg_size_pretty(pg_total_relation_size('public.l_bati_agrege_pepci_006_2023'));
--> 100 MB
---- On vacuum
VACUUM FULL public.l_bati_agrege_pepci_006_2023;
SELECT pg_size_pretty(pg_total_relation_size('public.l_bati_agrege_pepci_006_2023'));
--> 97 MB
--- On réindexe
REINDEX TABLE public.l_bati_agrege_pepci_006_2023;
SELECT pg_size_pretty(pg_total_relation_size('public.l_bati_agrege_pepci_006_2023'));
--> 97 MB

---- Test 1 : ST_ReducePrecision à 0.01
DROP TABLE IF EXISTS public.l_bati_agrege_pepci_006_2023_t1;
CREATE TABLE public.l_bati_agrege_pepci_006_2023_t1
(LIKE p_enveloppe_bati_2023.l_bati_agrege_pepci_006_2023 INCLUDING ALL);
ALTER TABLE IF EXISTS public.l_bati_agrege_pepci_006_2023_t1
CLUSTER ON l_bati_agrege_pepci_006_2023_t1_geom_idx;
INSERT INTO public.l_bati_agrege_pepci_006_2023_t1
SELECT * FROM p_enveloppe_bati_2023.l_bati_agrege_pepci_006_2023;
--> Updated Rows 305707
UPDATE public.l_bati_agrege_pepci_006_2023_t1
SET geom= ST_ReducePrecision(geom, 0.01)
WHERE ST_IsValid(geom)
-- Vérifie que la simplification ne change pas le nombre de polygones ou de points
AND ST_GeometryType(geom) = ST_GeometryType(ST_ReducePrecision(geom, 0.01))
-- Vérifie que la simplification ne vide pas la géographie
AND ST_Area(ST_ReducePrecision(geom,0.01)) > 0;
--> Updated Rows 305699
SELECT pg_size_pretty(pg_total_relation_size('public.l_bati_agrege_pepci_006_2023_t1'));
--> 194 MB
---- On optimise
VACUUM FULL public.l_bati_agrege_pepci_006_2023_t1;
REINDEX TABLE public.l_bati_agrege_pepci_006_2023_t1;
SELECT pg_size_pretty(pg_total_relation_size('public.l_bati_agrege_pepci_006_2023_t1'));
--> 196 MB

---- Test 2 : ST_SnapToGrid à 0.01
DROP TABLE IF EXISTS public.l_bati_agrege_pepci_006_2023_t2;
CREATE TABLE public.l_bati_agrege_pepci_006_2023_t2
(LIKE p_enveloppe_bati_2023.l_bati_agrege_pepci_006_2023 INCLUDING ALL);
ALTER TABLE IF EXISTS public.l_bati_agrege_pepci_006_2023_t2
CLUSTER ON l_bati_agrege_pepci_006_2023_t2_geom_idx;
INSERT INTO public.l_bati_agrege_pepci_006_2023_t2
SELECT * FROM p_enveloppe_bati_2023.l_bati_agrege_pepci_006_2023;
--> Updated Rows 305707
UPDATE public.l_bati_agrege_pepci_006_2023_t2
SET geom= ST_SnapToGrid(geom, 0.01)
WHERE ST_IsValid(geom) AND ST_IsValid(ST_SnapToGrid(geom, 0.01))
-- Vérifie que la simplification ne change pas le nombre de polygones ou de points
AND ST_GeometryType(geom) = ST_GeometryType(ST_SnapToGrid(geom, 0.01))
-- Vérifie que la simplification ne vide pas la géographie
AND ST_Area(ST_SnapToGrid(geom, 0.01)) > 0;
--> Updated Rows 305311
SELECT pg_size_pretty(pg_total_relation_size('public.l_bati_agrege_pepci_006_2023_t2'));
--> 195 MB
---- On optimise
VACUUM FULL public.l_bati_agrege_pepci_006_2023_t2;
REINDEX TABLE public.l_bati_agrege_pepci_006_2023_t2;
SELECT pg_size_pretty(pg_total_relation_size('public.l_bati_agrege_pepci_006_2023_t2'));
--> 195 MB

--- Test 3 : ST_QuantizeCoordinates
DROP TABLE IF EXISTS public.l_bati_agrege_pepci_006_2023_t3;
CREATE TABLE public.l_bati_agrege_pepci_006_2023_t3
(LIKE p_enveloppe_bati_2023.l_bati_agrege_pepci_006_2023 INCLUDING ALL);
ALTER TABLE IF EXISTS public.l_bati_agrege_pepci_006_2023_t3
CLUSTER ON l_bati_agrege_pepci_006_2023_t3_geom_idx;
INSERT INTO public.l_bati_agrege_pepci_006_2023_t3
SELECT * FROM p_enveloppe_bati_2023.l_bati_agrege_pepci_006_2023;
--> Updated Rows 305707
UPDATE public.l_bati_agrege_pepci_006_2023_t3
SET geom = ST_QuantizeCoordinates(geom, 0)
WHERE ST_IsValid(geom) AND ST_IsValid(ST_QuantizeCoordinates(geom, 0))
-- Vérifie que la simplification ne change pas le nombre de polygones ou de points
AND ST_GeometryType(geom) = ST_GeometryType(ST_QuantizeCoordinates(geom, 0))
-- Vérifie que la simplification ne vide pas la géographie
AND ST_Area(ST_QuantizeCoordinates(geom, 0)) > 0;
--> Updated Rows 300855
SELECT pg_size_pretty(pg_total_relation_size('public.l_bati_agrege_pepci_006_2023_t3'));
--> 191 MB
---- On optimise
VACUUM FULL public.l_bati_agrege_pepci_006_2023_t3;
REINDEX TABLE public.l_bati_agrege_pepci_006_2023_t3;
SELECT pg_size_pretty(pg_total_relation_size('public.l_bati_agrege_pepci_006_2023_t3'));
--> 192 MB

Si vous avez un semblant d'explication, je veux bien car je sèche un peu. Ne pas gagner de la place car la géométrie est stockée d'une même manière quelle que soit sa précision… je peux comprendre.

Mais doubler la taille initiale… j'étais loin de m'en douter.

d'avance merci à celles et ceux qui prendront le temps de me lire et de me répondre.

Nicolas Ribot · Mon 21 October 2024 11:30

Bonjour,

Sur quelle version de postgres/postgis ?

Nicolas

tumasgiu · Mon 21 October 2024 12:03

Bonjour,

à tout hasard vous pouvez ajouter pg_relation_size et pg_indexes_size à vos requêtes ?

Nicolas Ribot · Mon 21 October 2024 13:04

Pour gagner en place et vitesse, vous pouvez simplifier les géométries avec st_simpifyPreserveTopology

Nicolas

Nicolas Ribot · Mon 21 October 2024 13:08

Les colonnes geom ont toutes le meme type de stockage (storage) dans les tables ?

\d+ <table> donne cette info dans psql

Il y a des stockages qui compressent la géométrie et d'autres non

Nicolas

Nicolas Ribot · Mon 21 October 2024 13:30

Un test rapidos sur une table de ~2000 polygones donne ca:

Code:

select postgis_full_version();
-- POSTGIS="3.4.2 c19ce56" [EXTENSION] PGSQL="160" GEOS="3.13.0-CAPI-1.19.0" (compiled against GEOS 3.12.2) SFCGAL="SFCGAL 1.5.2, CGAL 5.6.1, BOOST 1.86.0" PROJ="9.5.0 NETWORK_ENABLED=OFF URL_ENDPOINT=https://cdn.proj.org USER_WRITABLE_DIRECTORY=/Users/nicolas.ribot/Library/Application Support/proj DATABASE_PATH=/opt/homebrew/Cellar/proj/9.5.0/share/proj/proj.db" GDAL="GDAL 3.9.2, released 2024/08/13" LIBXML="2.9.13" LIBJSON="0.18" RASTER

vacuum full nuts_europe;
-- Table "public.nuts_europe"
-- +------------+-----------------------------+-----------+----------+-----------------------------------------+----------+-------------+--------------+-------------+
-- |   Column   |            Type             | Collation | Nullable |                 Default                 | Storage  | Compression | Stats target | Description |
-- +------------+-----------------------------+-----------+----------+-----------------------------------------+----------+-------------+--------------+-------------+
-- | id         | integer                     |           | not null | nextval('nuts_europe_id_seq'::regclass) | plain    |             |              |             |
-- | geom       | geometry(MultiPolygon,4326) |           |          |                                         | main     |             |              |             |
-- | nuts_id    | character varying(5)        |           |          |                                         | extended |             |              |             |
-- | levl_code  | integer                     |           |          |                                         | plain    |             |              |             |
-- | cntr_code  | character varying(2)        |           |          |                                         | extended |             |              |             |
-- | name_latn  | character varying(70)       |           |          |                                         | extended |             |              |             |
-- | nuts_name  | character varying(106)      |           |          |                                         | extended |             |              |             |
-- | mount_type | integer                     |           |          |                                         | plain    |             |              |             |
-- | urbn_type  | integer                     |           |          |                                         | plain    |             |              |             |
-- | coast_type | integer                     |           |          |                                         | plain    |             |              |             |
-- | fid        | character varying(5)        |           |          |                                         | extended |             |              |             |
-- +------------+-----------------------------+-----------+----------+-----------------------------------------+----------+-------------+--------------+-------------+
-- Indexes:
--     "nuts_europe_pkey" PRIMARY KEY, btree (id)
-- Access method: heap

select pg_size_pretty(pg_total_relation_size('nuts_europe')) as tot,
       pg_size_pretty(pg_relation_size('nuts_europe')) as tab,
       pg_size_pretty(pg_indexes_size('nuts_europe')) as idx;
-- +-----+-------+-----+
-- |tot  |tab    |idx  |
-- +-----+-------+-----+
-- |30 MB|6056 kB|64 kB|
-- +-----+-------+-----+


create table t1 as
select n.id,
       st_snaptogrid(n.geom, 0.01) as geom,
       n.nuts_id,
       n.levl_code,
       n.cntr_code,
       n.name_latn,
       n.nuts_name,
       n.mount_type,
       n.urbn_type,
       n.coast_type,
       n.fid
from nuts_europe n;

alter table t1 add primary key (id);
vacuum analyze t1;

select pg_size_pretty(pg_total_relation_size('t1')) as tot,
       pg_size_pretty(pg_relation_size('t1')) as tab,
       pg_size_pretty(pg_indexes_size('t1')) as idx;
-- +-------+-------+-----+
-- |tot    |tab    |idx  |
-- +-------+-------+-----+
-- |7224 kB|4736 kB|64 kB|
-- +-------+-------+-----+

create table t2 as
select n.id,
       st_reduceprecision(n.geom, 0.01) as geom,
       n.nuts_id,
       n.levl_code,
       n.cntr_code,
       n.name_latn,
       n.nuts_name,
       n.mount_type,
       n.urbn_type,
       n.coast_type,
       n.fid
from nuts_europe n;

alter table t2 add primary key (id);
vacuum analyze t2;

select pg_size_pretty(pg_total_relation_size('t2')) as tot,
       pg_size_pretty(pg_relation_size('t2')) as tab,
       pg_size_pretty(pg_indexes_size('t2')) as idx;
-- +-------+-------+-----+
-- |tot    |tab    |idx  |
-- +-------+-------+-----+
-- |6792 kB|4608 kB|64 kB|
-- +-------+-------+-----+

create table t3 as
select n.id,
       st_quantizecoordinates(n.geom, 0) as geom,
       n.nuts_id,
       n.levl_code,
       n.cntr_code,
       n.name_latn,
       n.nuts_name,
       n.mount_type,
       n.urbn_type,
       n.coast_type,
       n.fid
from nuts_europe n;

alter table t3 add primary key (id);
vacuum analyze t3;

select pg_size_pretty(pg_total_relation_size('t3')) as tot,
       pg_size_pretty(pg_relation_size('t3')) as tab,
       pg_size_pretty(pg_indexes_size('t3')) as idx;
-- +-------+-------+-----+
-- |tot    |tab    |idx  |
-- +-------+-------+-----+
-- |1624 kB|1216 kB|64 kB|
-- +-------+-------+-----+

Soit un bon gain de taille, notamment avec st_quantize !

Nicolas

Dernière modification par Nicolas Ribot (Mon 21 October 2024 13:31)

badol · Mon 21 October 2024 13:43

Bonjour,

Merci pour tous ces renseignements, çà m'aide beaucoup.

J'ai fait les tests ce week-end sur mon serveur perso qui a la dernière version de PostGis : 3.5 sous debian

Je viens de refaire les tests avec mon serveur pro (redhat et POSTGIS="3.1.11 ca03d62" [EXTENSION] PGSQL="130" GEOS="3.12.1-CAPI-1.18.1" PROJ="9.4.0" LIBXML="2.9.13" LIBJSON="0.14" LIBPROTOBUF="1.3.3" WAGYU="0.5.0 (Internal)")

Je n'ai plus de doublement de la table ... pour l'instant elle reste de la même taille.

Une différence majeure entre mes tests d'hier et ceux de ce midi :
- hier le cartouche spatial était défini en geometry('POLYGON', 2154)
- ce midi : geometry('MULTIPOLYGON', 2154)

Je refais les tests et vous tiens au courant des suites.

badol · Mon 21 October 2024 14:08

re-bonjour,

je viens de travailler sur une autre table comme support avec Postgis 3.1.11

Code:

select postgis_full_version();
/*
postgis_full_version                                                                                                                                               |
-------------------------------------------------------------------------------------------------------------------------------------------------------------------+
POSTGIS="3.1.11 ca03d62" [EXTENSION] PGSQL="130" GEOS="3.12.1-CAPI-1.18.1" PROJ="9.4.0" LIBXML="2.9.13" LIBJSON="0.14" LIBPROTOBUF="1.3.3" WAGYU="0.5.0 (Internal)"|
*/

Les résultats sont les suivants

---- Situation initiale (en Lambert93):

Code:

DROP TABLE IF EXISTS public.n_batiment_pepci_001_2024;
CREATE TABLE public.n_batiment_pepci_001_2024
    (LIKE r_parcellaire_express_2024.n_batiment_pepci_001_2024 INCLUDING ALL);
ALTER TABLE IF EXISTS public.n_batiment_pepci_001_2024
    CLUSTER ON n_batiment_pepci_001_2024_geom_idx;
INSERT INTO public.n_batiment_pepci_001_2024
    SELECT * FROM r_parcellaire_express_2024.n_batiment_pepci_001_2024;
--> Updated Rows    576946
select pg_size_pretty(pg_total_relation_size('public.n_batiment_pepci_001_2024')) as tot,
       pg_size_pretty(pg_relation_size('public.n_batiment_pepci_001_2024')) as tab,
       pg_size_pretty(pg_indexes_size('public.n_batiment_pepci_001_2024')) as idx;
/*
tot   |tab   |idx  |
------+------+-----+
163 MB|123 MB|40 MB|
*/
---- On vacuum
VACUUM FULL public.n_batiment_pepci_001_2024;
select pg_size_pretty(pg_total_relation_size('public.n_batiment_pepci_001_2024')) as tot,
       pg_size_pretty(pg_relation_size('public.n_batiment_pepci_001_2024')) as tab,
       pg_size_pretty(pg_indexes_size('public.n_batiment_pepci_001_2024')) as idx;
/*
tot   |tab   |idx  |
------+------+-----+
166 MB|123 MB|43 MB|
*/
--- On réindexe
REINDEX TABLE public.n_batiment_pepci_001_2024;
select pg_size_pretty(pg_total_relation_size('public.n_batiment_pepci_001_2024')) as tot,
       pg_size_pretty(pg_relation_size('public.n_batiment_pepci_001_2024')) as tab,
       pg_size_pretty(pg_indexes_size('public.n_batiment_pepci_001_2024')) as idx;
/*
tot   |tab   |idx  |
------+------+-----+
166 MB|123 MB|43 MB|
*/

--- Test 4 : ST_QuantizeCoordinates sans autre contrainte

Code:

DROP TABLE IF EXISTS public.n_batiment_pepci_001_2024_t4;
CREATE TABLE public.n_batiment_pepci_001_2024_t4 AS
SELECT 
    gid,
    TYPE,
    ST_QuantizeCoordinates(geom, 0) AS geom
FROM r_parcellaire_express_2024.n_batiment_pepci_001_2024;
--> Updated Rows    576946
select pg_size_pretty(pg_total_relation_size('public.n_batiment_pepci_001_2024_t4')) as tot,
       pg_size_pretty(pg_relation_size('public.n_batiment_pepci_001_2024_t4')) as tab,
       pg_size_pretty(pg_indexes_size('public.n_batiment_pepci_001_2024_t4')) as idx;
/*
tot   |tab   |idx    |
------+------+-------+
123 MB|123 MB|0 bytes|
*/

Bref aucun gain.

Dernière modification par badol (Mon 21 October 2024 14:13)

n314 · Mon 21 October 2024 14:36

y'aurait pas un truc avec le "cluster on" ?
https://www.postgresql.org/docs/current … uster.html

When an index scan is used, a temporary copy of the table is created that contains the table data in the index order. Temporary copies of each index on the table are created as well. Therefore, you need free space on disk at least equal to the sum of the table size and the index sizes.

badol · Mon 21 October 2024 14:40

n314 a écrit:

y'aurait pas un truc avec le "cluster on" ?
https://www.postgresql.org/docs/current … uster.html
When an index scan is used, a temporary copy of the table is created that contains the table data in the index order. Temporary copies of each index on the table are created as well. Therefore, you need free space on disk at least equal to the sum of the table size and the index sizes.

Pour le test 4 ... il n'y a pas de cluster sur la nouvelle table générée, pourtant le gain n'est pas probant non plus.

n314 · Mon 21 October 2024 15:11

badol a écrit:

Pour le test 4 ... il n'y a pas de cluster sur la nouvelle table générée, pourtant le gain n'est pas probant non plus.

y'a pas le VACUUM FULL non plus sur ce test, si ?

badol · Mon 21 October 2024 16:16

n314 a écrit:

y'a pas le VACUUM FULL non plus sur ce test, si ?

Effectivement j'ai oublié de le préciser, mais si si y'avais un VACUUM FULL de fait.

Code:

--- Test 4 : ST_QuantizeCoordinates sans autre contrainte
DROP TABLE IF EXISTS public.n_batiment_pepci_001_2024_t4;
CREATE TABLE public.n_batiment_pepci_001_2024_t4 AS
SELECT 
    gid,
    TYPE,
    ST_QuantizeCoordinates(geom, 0) AS geom
FROM r_parcellaire_express_2024.n_batiment_pepci_001_2024;
--> Updated Rows    576946
select pg_size_pretty(pg_total_relation_size('public.n_batiment_pepci_001_2024_t4')) as tot,
       pg_size_pretty(pg_relation_size('public.n_batiment_pepci_001_2024_t4')) as tab,
       pg_size_pretty(pg_indexes_size('public.n_batiment_pepci_001_2024_t4')) as idx;
/*
tot   |tab   |idx    |
------+------+-------+
123 MB|123 MB|0 bytes|
*/             
VACUUM FULL public.n_batiment_pepci_001_2024_t4;
REINDEX TABLE public.n_batiment_pepci_001_2024_t4;
select pg_size_pretty(pg_total_relation_size('public.n_batiment_pepci_001_2024_t4')) as tot,
       pg_size_pretty(pg_relation_size('public.n_batiment_pepci_001_2024_t4')) as tab,
       pg_size_pretty(pg_indexes_size('public.n_batiment_pepci_001_2024_t4')) as idx;
/*
tot   |tab   |idx    |
------+------+-------+
123 MB|123 MB|0 bytes|
*/

Dernière modification par badol (Mon 21 October 2024 16:20)

ChristopheV · Wed 23 October 2024 07:28

Bonjour,

Je suis un peu surpris.
Avant même de parler de postgis, il est nécessaire de parler d'informatique basique.
Que vous ayez 9 chiffres après la virgule ou deux, l'espace l'espace utilisé est le même. 32bits ou 64 suivant les systèmes.

Comme l'indique Nicolas Ribot, si vous voulez gagner de la place et de la vitesse, il faut simplifier les géométries quand cela est possible.
C'est le nombre de sommets d'une "linestring" ou d'un "polygon" qui influe sur le stockage et la vitesse de traitement.

Ce n'est pas une question de base de données, mais de codage et d'algorithmique.

badol · Thu 24 October 2024 11:56

ChristopheV a écrit:

Bonjour,
Je suis un peu surpris

Il ne faut pas l'être ;-)

Nous sommes dans un processus de gain de place poussé, toutes les autres démarches classiques sont maitrisées et appliquées. C'est vrai que je ne l'ai pas précisé.

St_SimplifyPreserveTopology & St_Simplify peuvent dégrader la donnée selon le paramètre de tolérance saisi. Ça c'est plutôt du métier de faire cela.

Un administrateur de base de données n'a pas d'amplitude sur cette partie sinon d'acculturer ses utilisateurs et de demander si cela a été fait.

Mais on diverge du problème rencontré.

Je vais continuer à creuser pourquoi Nicolas gagne de la place et moi j'en perds ...

ChristopheV · Fri 25 October 2024 10:25

Bonjour,

Badol a écrit:

J'ai beaucoup de tables en Lambert 93 avec 9 chiffres après la virgule.

J'avais subodoré que réduire cette précision inutile ferait gagner de la place sur le disque, augmenterait un peu la vitesse d'affichage et réduirait le temps des géotraitements.

Je réponds à la question posée.

badol · Fri 25 October 2024 11:10

J'ai creusé la partie cartouche spatial car j'étais surpris du gain de place dans la démonstration de Nicolas Ribot.
Gain de place qu'on définisse le cartouche en geometry('MULTIPOLYGON',2154) en geometry(multipolygon,2154) en geometry(multipolygon) ou en geometry tout simple

Code:

---- Le cartouche comme actuellement défini
DROP TABLE IF EXISTS public.n_batiment_pepci_001_2024_t5;
CREATE TABLE public.n_batiment_pepci_001_2024_t5
    (LIKE r_parcellaire_express_2024.n_batiment_pepci_001_2024 INCLUDING ALL);
ALTER TABLE public.n_batiment_pepci_001_2024_t5
ALTER COLUMN geom TYPE geometry('MULTIPOLYGON',2154);
INSERT INTO public.n_batiment_pepci_001_2024_t5
    SELECT * FROM r_parcellaire_express_2024.n_batiment_pepci_001_2024;      
VACUUM FULL public.n_batiment_pepci_001_2024_t5;
REINDEX TABLE public.n_batiment_pepci_001_2024_t5;
select pg_size_pretty(pg_total_relation_size('public.n_batiment_pepci_001_2024_t5')) as tot,
       pg_size_pretty(pg_relation_size('public.n_batiment_pepci_001_2024_t5')) as tab,
       pg_size_pretty(pg_indexes_size('public.n_batiment_pepci_001_2024_t5')) as idx;
/*
tot   |tab   |idx  |
------+------+-----+
166 MB|123 MB|43 MB|
*/       
      
---- Le cartouche façon dbeaver
DROP TABLE IF EXISTS public.n_batiment_pepci_001_2024_t6;
CREATE TABLE public.n_batiment_pepci_001_2024_t6
    (LIKE r_parcellaire_express_2024.n_batiment_pepci_001_2024 INCLUDING ALL);
ALTER TABLE public.n_batiment_pepci_001_2024_t6
ALTER COLUMN geom TYPE geometry(multipolygon,2154);
INSERT INTO public.n_batiment_pepci_001_2024_t6
    SELECT * FROM r_parcellaire_express_2024.n_batiment_pepci_001_2024;      
VACUUM FULL public.n_batiment_pepci_001_2024_t6;
REINDEX TABLE public.n_batiment_pepci_001_2024_t6;
select pg_size_pretty(pg_total_relation_size('public.n_batiment_pepci_001_2024_t6')) as tot,
       pg_size_pretty(pg_relation_size('public.n_batiment_pepci_001_2024_t6')) as tab,
       pg_size_pretty(pg_indexes_size('public.n_batiment_pepci_001_2024_t6')) as idx;
/*
tot   |tab   |idx  |
------+------+-----+
166 MB|123 MB|43 MB|
*/       

---- Le cartouche sans projection
DROP TABLE IF EXISTS public.n_batiment_pepci_001_2024_t7;
CREATE TABLE public.n_batiment_pepci_001_2024_t7
    (LIKE r_parcellaire_express_2024.n_batiment_pepci_001_2024 INCLUDING ALL);
ALTER TABLE public.n_batiment_pepci_001_2024_t7
ALTER COLUMN geom TYPE geometry(multipolygon);
INSERT INTO public.n_batiment_pepci_001_2024_t7
    SELECT * FROM r_parcellaire_express_2024.n_batiment_pepci_001_2024;      
VACUUM FULL public.n_batiment_pepci_001_2024_t7;
REINDEX TABLE public.n_batiment_pepci_001_2024_t7;
select pg_size_pretty(pg_total_relation_size('public.n_batiment_pepci_001_2024_t7')) as tot,
       pg_size_pretty(pg_relation_size('public.n_batiment_pepci_001_2024_t7')) as tab,
       pg_size_pretty(pg_indexes_size('public.n_batiment_pepci_001_2024_t7')) as idx;
/*
tot   |tab   |idx  |
------+------+-----+
166 MB|123 MB|43 MB|
*/       

---- Le cartouche sans rien
DROP TABLE IF EXISTS public.n_batiment_pepci_001_2024_t8;
CREATE TABLE public.n_batiment_pepci_001_2024_t8
    (LIKE r_parcellaire_express_2024.n_batiment_pepci_001_2024 INCLUDING ALL);
ALTER TABLE public.n_batiment_pepci_001_2024_t8
ALTER COLUMN geom TYPE geometry;
INSERT INTO public.n_batiment_pepci_001_2024_t8
    SELECT * FROM r_parcellaire_express_2024.n_batiment_pepci_001_2024;      
VACUUM FULL public.n_batiment_pepci_001_2024_t8;
REINDEX TABLE public.n_batiment_pepci_001_2024_t8;
select pg_size_pretty(pg_total_relation_size('public.n_batiment_pepci_001_2024_t8')) as tot,
       pg_size_pretty(pg_relation_size('public.n_batiment_pepci_001_2024_t8')) as tab,
       pg_size_pretty(pg_indexes_size('public.n_batiment_pepci_001_2024_t8')) as idx;
/*
tot   |tab   |idx  |
------+------+-----+
166 MB|123 MB|43 MB|
*/

Dernière modification par badol (Fri 25 October 2024 11:11)

badol · Fri 25 October 2024 11:25

Nicolas Ribot a écrit:

Un test rapidos sur une table de ~2000 polygones donne ca:

Soit un bon gain de taille, notamment avec st_quantize !

Nicolas

J'ai l'explication des résultats de Nicolas

0.01 degrés en WGS84 çà fait à la louche 1,1 km en latitude et 785 m en longitude… donc il ne réduit pas la précision au cm comme j'essaye de faire mais au km ;-)

pour aller plus loin : https://chatgpt.com/share/671b62a5-9364 … 5e547e971.

Je clos le sujet ... aucun gain à attendre de tout cela.

Merci pour votre aide.
Désolé pour vous avoir fait perdre votre temps

Dernière modification par badol (Fri 25 October 2024 11:38)

Communauté	Ressources	L'emploi	Le marché	L'association	Fils RSS
Forum Blogs Wiki Planet Sites amis	Agenda Biblio Fiches AMO-CNIG Paris PCGIS Téléchargements	Offres d'emploi Banque de CV Formations Démarche Métiers	Geo-Entreprises Geo-Communiqué Appels d'offres	L'association Qui sommes-nous ? Nous aider Bienfaiteurs Partenaires Historique Statuts	Tout le site Job Géomatique Services GeoBlogs ...	Faire un don Mentions légales

Le portail francophone de la géomatique

#1 Mon 21 October 2024 07:36

Réduire la précision géométrique augmente la taille ?

#2 Mon 21 October 2024 11:30

Re: Réduire la précision géométrique augmente la taille ?

#3 Mon 21 October 2024 12:03

Re: Réduire la précision géométrique augmente la taille ?

#4 Mon 21 October 2024 13:04

Re: Réduire la précision géométrique augmente la taille ?

#5 Mon 21 October 2024 13:08

Re: Réduire la précision géométrique augmente la taille ?

#6 Mon 21 October 2024 13:30

Re: Réduire la précision géométrique augmente la taille ?

Code:

#7 Mon 21 October 2024 13:43

Re: Réduire la précision géométrique augmente la taille ?

#8 Mon 21 October 2024 14:08

Re: Réduire la précision géométrique augmente la taille ?

Code:

Code:

Code:

#9 Mon 21 October 2024 14:36

Re: Réduire la précision géométrique augmente la taille ?

#10 Mon 21 October 2024 14:40

Re: Réduire la précision géométrique augmente la taille ?

#11 Mon 21 October 2024 15:11

Re: Réduire la précision géométrique augmente la taille ?

#12 Mon 21 October 2024 16:16

Re: Réduire la précision géométrique augmente la taille ?

Code:

#13 Wed 23 October 2024 07:28

Re: Réduire la précision géométrique augmente la taille ?

#14 Thu 24 October 2024 11:56

Re: Réduire la précision géométrique augmente la taille ?

#15 Fri 25 October 2024 10:25

Re: Réduire la précision géométrique augmente la taille ?

#16 Fri 25 October 2024 11:10

Re: Réduire la précision géométrique augmente la taille ?

Code:

#17 Fri 25 October 2024 11:25

Re: Réduire la précision géométrique augmente la taille ?

Pied de page des forums