PostgreSQL La base de donnees la plus sophistiquee au monde.

Forums PostgreSQL.fr

Le forum officiel de la communauté francophone de PostgreSQL

Vous n'êtes pas identifié(e).

#1 Général » Prolème de configuration ? » 07/10/2009 16:38:59

charli0123
Réponses : 0

Bonjour à tous,

Je viens requérir votre aide  pour un petit problème !
Nous avons installé pour la première fois il y a peu une base PostgreSql et nous avons des problèmes de temps d'accès aux données, voir d'accès aux données tout court ... je m'explique par un exemple :

Si un de mes collègues lance une requête en update sur une table TOTO ( cette requête dure environ 10 minutes car on est sur une grosse table ) via PhpPgAdmin ou un traitement php qu'importe.

On ne peut alors plus ou avec une extrême lenteur accéder aux programmes de l'application pointant sur la même base mais qui n'accède pas forcément à la même table.

J'imagine qu'il y a tout pleins de paramètres  à tester mais le php.ini .... ce n'est pas mon truc d'où mon appel à l'aide.

Je vous remercie par avance pour vos conseils et votre aide

cordialement

Charles

#2 Re : Général » Interêt du partitionnement de ma table » 21/09/2009 15:22:14

Merci bien pour toutes ces réponses et pour avoir pris le temps d'analyser ma situation , je vais prendre le parti de na pas partitionner ma table pour le moment. On verra si un jour il y a de fort ralentissement .... à ce moment là , je repasserai poser ma question ;-)

#3 Re : Général » Interêt du partitionnement de ma table » 21/09/2009 14:43:26

Pour le moment il n'y a de toute façon pas assez de données pour qu'il y ait un problème de ralentissement ( ce n'est pas moi qui alimente cette table! ). La vision est à plus long terme ; en fait on imagine qu'il y aura un problème d'accès à un moment ou un autre ( vu que l'index unique contient quasiment tous les champs de la table ) quand il y aura plusieurs dizaine de millions de lignes. (l'historique se créera petit à petit ) . mais on aura jamais une table plus grosse que les 8Go annoncé au début.

le partitionnement sera donc forcément plus lent si j'ai peu de données dans ma table, ce que je conçois tout à fait. Mais sera-t-il plus performant qu'une table seule lorsqu'il y aura 100 millions de lignes dans ma table ? En gros , est-ce que ça vaut le coup d'anticiper , ou bien dois-je attendre que mon application rame pour essayer d'optimiser la table ?

un exemple de requete sans doute lourdre à terme :

select * from toto where cprp_toto= '009221' and  type='PUB' and num_toto='0' and now() between datdeb_toto and datfin_toto

#4 Re : Général » Interêt du partitionnement de ma table » 21/09/2009 13:55:54

Alors ,

- Effectivement je n'ai pas mis d'index sur la table toto car elle ne contient aucune données. (j'ai suivi les conseils de la doc .... non ? )

- Il n'y a effectivement qu'un index unqiue sur chaque table fille qui est celui de la clé primaire (cprp_toto, type_toto, num_toto, datdeb_toto, datfin_toto) ; je n'ai pas mis d'index sur type_toto uniquement car chaque table fille n'a forcément qu'un type possible ; c'est apparement une erreur ....

- Je pensais avoir écrit une contrainte sur chaque table fille :
exemple : CHECK ((type_toto)::text = 'PUB'::text) pour la table toto_pub comme on peut le voir dans le message précédent, ça ne suffit pas ?

- j'ai bien mis en place la variable constraint_exclusion à ON dans PosgreSql.config

- Sinon voici un explain analyse sur la table toto ( non partitionnée ) :

explain analyse select * from toto where type_toto = 'PUB'

Seq Scan on taris  (cost=0.00..3.99 rows=20 width=63) (actual time=0.025..0.082 rows=20 loops=1)

  Filter: ((type_toto)::text = 'PUB'::text)

Total runtime: 0.144 ms

3 ligne(s)

Temps d'exécution total : 2.524 ms

En espérant avoir répondu à vos questions !

#5 Re : Général » Interêt du partitionnement de ma table » 21/09/2009 12:00:00

Désolé pour la longueur du message :
Voici un exemple simple de ce que j'ai fait

Voici ma table mère :

CREATE TABLE toto (
    cprp_toto character(6) NOT NULL,
    type_toto character varying(5) NOT NULL,
    num_toto smallint NOT NULL,
    datdeb_toto date NOT NULL,
    datfin_toto date NOT NULL,
    prix_toto numeric(10,5),
    datcre_toto timestamp without time zone,
    datmaj_toto timestamp without time zone,
    usermaj_toto character varying(12)
);

Règles d'insertion :

CREATE RULE rule_toto_achat AS ON INSERT TO toto WHERE (((((new.type_toto)::text = 'PNNPD'::text) OR ((new.type_toto)::text = 'PNN'::text)) OR ((new.type_toto)::text = 'PCTRL'::text)) OR ((new.type_toto)::text = 'PBT'::text)) DO INSTEAD INSERT INTO toto_achat (cprp_toto, type_toto, num_toto, datdeb_toto, datfin_toto, prix_toto, datcre_toto, datmaj_toto, usermaj_toto) VALUES (new.cprp_toto, new.type_toto, new.num_toto, new.datdeb_toto, new.datfin_toto, new.prix_toto, new.datcre_toto, new.datmaj_toto, new.usermaj_toto);

CREATE RULE rule_toto_ces AS ON INSERT TO toto WHERE ((new.type_toto)::text = 'CES'::text) DO INSTEAD INSERT INTO toto_ces (cprp_toto, type_toto, num_toto, datdeb_toto, datfin_toto, prix_toto, datcre_toto, datmaj_toto, usermaj_toto) VALUES (new.cprp_toto, new.type_toto, new.num_toto, new.datdeb_toto, new.datfin_toto, new.prix_toto, new.datcre_toto, new.datmaj_toto, new.usermaj_toto);

CREATE RULE rule_toto_pub AS ON INSERT TO toto WHERE ((new.type_toto)::text = 'PUB'::text) DO INSTEAD INSERT INTO toto_pub (cprp_toto, type_toto, num_toto, datdeb_toto, datfin_toto, prix_toto, datcre_toto, datmaj_toto, usermaj_toto) VALUES (new.cprp_toto, new.type_toto, new.num_toto, new.datdeb_toto, new.datfin_toto, new.prix_toto, new.datcre_toto, new.datmaj_toto, new.usermaj_toto);


Tables Filles :
/**************************************************************************************/
CREATE TABLE toto_achat (CONSTRAINT toto_achat_type_toto_check CHECK ((type_toto)::text = 'ACH'::text)
)
INHERITS (toto);

ALTER TABLE ONLY toto_achat
    ADD CONSTRAINT pk_toto_achat UNIQUE (cprp_toto, type_toto, num_toto, datdeb_toto, datfin_toto);
/**************************************************************************************/
CREATE TABLE toto_ces (CONSTRAINT toto_achat_type_toto_check CHECK ((type_toto)::text = 'CES'::text)
)
INHERITS (toto);

ALTER TABLE ONLY toto_ces
    ADD CONSTRAINT pk_toto_ces UNIQUE (cprp_toto, type_toto, num_toto, datdeb_toto, datfin_toto);
/**************************************************************************************/
CREATE TABLE toto_pub (CONSTRAINT toto_achat_type_toto_check CHECK ((type_toto)::text = 'PUB'::text)
)
INHERITS (toto);

ALTER TABLE ONLY toto_pub
    ADD CONSTRAINT pk_toto_pub UNIQUE (cprp_toto, type_toto, num_toto, datdeb_toto, datfin_toto);
/**************************************************************************************/

Quand la table est partitionnée :

explain select * from toto where type_toto='pub'

Result  (cost=0.00..3.02 rows=1 width=74)

  ->  Append  (cost=0.00..3.02 rows=1 width=74)

        ->  Seq Scan on toto  (cost=0.00..3.02 rows=1 width=74)

              Filter: ((type_toto)::text = 'pub'::text)

Temps d'exécution total : 3.814 ms ( moyenne de plusieurs essai )

/**************************************************************************************/
Quand la table n'est pas partitionnée :

explain select * from toto where type_toto='pub'

Result  (cost=0.00..3.99 rows=1 width=63)

  ->  Append  (cost=0.00..3.99 rows=1 width=63)

        ->  Seq Scan on toto  (cost=0.00..3.99 rows=1 width=63)

              Filter: ((type_toto)::text = 'pub'::text)

Temps d'exécution total : 3.860 ms  (moyenne de plusieurs essai )

Sinon il y a aussi des accès sur les dates mais j'ai pas le code sous la main pour fournir des requêtes plus complexes.

#6 Re : Général » Interêt du partitionnement de ma table » 21/09/2009 11:38:20

Bonjour,

Merci de cette réponse si rapide !
Effectivement je n'ai  pas été très précis .
Le but du partitionnement serait ici d'accélérer le select plutôt que l'insert.
De plus, je n'ai pas un serveur extrêmement puissant mais mon problème vient surtout du fait que beaucoup de personne auront un accès simultané aux données de cette tables en lecture ( et écriture -> beaucoup moins fréquent ) via une application PHP  et mon cher DBA se demande si le serveur va tenir le coup , vu qu'il rame déjà en développement .

Du coup on me demande d'essayer d'optimiser les accès aux tables de plus gros volume pour avoir des temps de réponses plus faibles. ( remarque : c'est toujours la faute du développeur ! ;-) )

Or pour le moment, le partionnement ( peut être m'y suis-je mal pris aussi .... )  et les indexes partiels n'y change rien et je pense moi aussi qu'une table de 8 Go n'est pas une grosse table et que c'est plutôt le serveur qui est trop faible puisqu'il "ralentit" dès que plusieurs personnes se trouvent dessus.

Mais dans  le doute ... je m'informe !

#7 Général » Interêt du partitionnement de ma table » 21/09/2009 11:17:26

charli0123
Réponses : 11

Bonjour,

Je m'excuse d'avance si ce sujet à déjà été abordé ici , mais je n'ai pas trouvé de réponses dans la recherche.

J'ai créé une table qui à terme devrait faire entre 5 et 8 Go.

Ais-je un intérêt particulier à la partitionner ?

J'ai cru lire ici et là qu'il fallait des tables avec de gros volumes pour que le partitionnement soit utile ; mais pour moi 8 Go ... c'est un gros volume ( merci de ne pas rire ! ;-) ) .

J'ai testé son partionnement , mais avec moins d'un millions de lignes c'est moins performant.... d'où ma question ci-dessus ; j'ai testé les indexes partiels aussi mais ça n'améliore pas la situation non plus ( situation qui est tout à fait acceptable pour le moment ).

Merci d'avoir pris le temps de me lire et merci encore à ceux qui prendront le temps de me répondre pour me donner leur avis.

Cordialement

Pied de page des forums

Propulsé par FluxBB