Forums PostgreSQL.fr

Le paramètre effective_cache_size donne a postgresql un moyen de déterminer si une donnée qui n est pas dans le cache postgres a des chances d'être dans le cache disque du système d'exploitation.
Ainsi, une grosse valeur aura tendance a diminuer l'utilisation des index, l'accès disque étant rendu plus rapide.

Vous devriez voir un changement de plan d'exécution dans le explain qui vous permettra de voir où se trouve le problème.

De plus, après un redémarrage du serveur il est probable que les données ne soient pas dans le cache système, le gain en performance ne sera alors visible qu'une fois les données remontées dans le cache système.

Une augmentation de plus de 10 minutes est à première vue déraisonnable. Si aucun verrou ne bloque l'accès cela peut être le signe de statistiques non à jour conduisant à de très mauvais plan d'exécution. Bref, il faut chercher dans plusieurs directions.

Pour les autres paramètres de configuration, le plus important est sans doute le shared_buffers qui dimensionne le cache postgresql et contribue le plus au gain de performance. Si vous êtes sous windows, il est par contre déconseillé de le passer à plus de 512MB.

Bonjour.
Que donne la vue pg_stat_activity lors du drop constraint ? La requête est-elle bloquée ? (waiting = true)

Bonjour,
si vous êtes en Postgresql 9.0 ou supérieur, vous pouvez le faire facilement avec les fonctions window

Pour votre exemple :

SELECT DISTINCT "Champ1",min("Champ2") OVER (PARTITION BY "Champ1")
FROM table

Pour avoir les 2 premières  valeurs de chaque Champ1, il faut imbriquer une requête :

SELECT "Champ1","Champ2" FROM (
  SELECT "Champ1","Champ2", row_number() OVER (PARTITION BY "Champ1" ORDER BY "Champ2") as rang
  FROM table
) sql
WHERE rang < 3

Edit : Oups, j'ai lu trop vite. Pour renvoyer la première valeur ou les 2 premières valeurs, il est necessaire d'avoir un champ supplémentaire (créer la table avec un oid ou avec un serial), sinon la requête ne pourra pas ramener forcément les même enregistrements, les données n'ayant pas réellement d'ordre. Il faut donc ensuite adapter les fonctions window avec le min ou le order sur le champ serial ou oid.

Bonjour.
Il n'y a pas d'autre moyen que pg_locks pour connaitre le verouillage des ligne d'une table.

Vous pouvez sinon utiliser un where  pour essayer paralléliser rapidement les traitements (par ex, s'il y a un champ séquence un modulo avec le nombre de processeurs sur la séquence) ou LIMIT et OFFSET.

Vous pouvez également utiliser l'option NOWAIT du SELECT FOR UPDATE dans une boucle et gérer l'exception en cas d'erreur, ce qui vous permettra de continuer le traitement, mais dans ce cas il sera peut-être dur de s'assurer que chaque ligne n'est traitée qu'une seule fois.

A priori non, sauf si la partition n'est pas visible pour l'utilisateur postgres.
Pouvez-vous ouvrir une session sur le serveur en tant que postgres et vérifier que le disque D et le répertoire data_pg_84 sont bien présent ?

Je crois que SAS proposait de remplacer le / par un \, mais ça ne pose pas de soucis normalement.

Sinon le disque D est-il un disque physique ? Et est-il accessible par l'utilisateur lançant le service postgresql ?

A priori il n'y a pas de raison que le service ne se lance pas. L'erreur se reproduit toujours si vous relancez le service ?

Bonjour.
Le dblink.sql contient la création de l'extension dblink :

CREATE EXTENSION dblink;

C'est cette commande qui va vous installer dblink sur le serveur.

Bonjour.
A première vue, il semblerait que l'initdb n'a pas pu se lancer car le répertoire d:\PostgresData existait déjà ou n'était pas vide.

correction des droits sur le r‚pertoire existant D:/PostgresData... ok
cr‚ation des sous-r‚pertoires... initdb : n'a pas pu cr‚er le r‚pertoire ® D:/PostgresData ¯ : File exists

Bonjour.

Il n'y a pas un cache de requête mais un cache de donnée. Grosso modo, lors d'une requête, si les données se trouvent dans le cache alors postgres n'a pas besoin de les lire du disque, et la requête est donc plus rapide à exécuter, le changement de durée dépendant de la vitesse disques.

Pour voir cela, vous pouvez utiliser l'option buffers du explain, qui vous dira si les blocs sont lus en mémoire (hit) ou sur disque (read).

explain (analyze,buffers) select count(*) as col_0_0_ from snsrBroadcast broadcast0_ where broadcast0_.gateway_id='52910199' limit 2

Coder en pl/c permet d'avoir un gros gain de performance, accès à beaucoup plus de fonctionnalités (création d'aggrégats par exemple) mais on perd une certaine souplesse, code compilé spécifique à une plateforme, il faut recompiler pour en changer voire faire des adaptations, pas de visibilité du code en direct etc.
Pour le perl, python etc ça permet d'avoir plus de liberté sur le serveur (gestion de fichier etc) et de garder un langage qu'on aime pour le faire, avec encore une fois plus de performance.
La plupart des contrib sont codés dans ces langages (les langages visible dans le fichier sql d'installation si vous êtes curieux)

Pour le reste, désolé mais je n'y connais rien ^^

Bonjour.
Si le serveur ne doit servir que d'intermédiaire entre les 2 autres serveur, c'est alors plutôtde la réplication en cascade qui sera disponible normalement en 9.2

La réplication native de postgresql ne permet pas de multi-maître, et de mémoire il n'existe que bucardo qui permette de le faire.
Slony permet de gérer plusieurs serveurs en écriture, du moment que les données répliquées ne sont pas écrites sur le serveur répliqué.

Sinon, avoir une réplication entre 2 serveurs et une liaison lente n'est franchement pas une bonne idée, et la solution de votre directeur ne ferait qu'ajouter un lag sur le 3eme serveur je pense.

Je n'ai pas utilisé l'installeur one-click depuis longtemps, mais il me semblait que l'on pouvait choisir entre créer un utilisateur spécifique pour postgres ou en utiliser un déjà existant.

Sinon, avez-vous installé le Visual C++ Redistributable Package 64 bits ?
http://www.microsoft.com/download/en/de … x?id=14632

Il se peut que le problème vienne de là.