Re: Petit conseil

Bonjour à tous,

Je suis la liste depuis quelques mois maintenant mais ceci est mon
premier message alors je vais vite fait me présenter:
Je me nomme Thibaut, je suis étudiant en informatique à supinfo (oué je
sais moyen) sur le récent site de Limoges et sinon je vis sur Sarlat en
Dordogne.
Je suis intéresse par tout ce qui est base de donnée et j'essaye
actuellement d'avoir des notions de bases sur les différents système
utilisées (MySQL, Oracle, Postgresql biensur, mais aussi SQL server, DB2
et autres...)

J'aurai bien aimé être présent lors des RMLL mais le programme ne me
plaisait que moyennement.
Et je ne pourrai malheureusement pas être présent lors de la PGDay car
je serai en stage en Eure-et-Loire à coder des script SQL et PL/SQL sur
les serveurs Oracle de chez MMA.

Je me suis donc intéressé à Postgresql car après quelques lectures sur
le net, j'ai vu que les performances de celui si pouvais rivaliser avec
Oracle et sans doute donc dépasser les limitations de MySQL que je
rencontre régulièrement en codant quelques sites relativement volumineux
en donnés.

J'en viens donc à me pauser quelques questions auxquelles je ne peux pas
encore répondre seul:

Pourquoi PostgreSQL plutôt que MySQL? (je suppose que ça reviens presque
au même pourquoi Oracle, hormis la question du prix et de la licence)

De la même manière quelle volume peut supporter Postgresql? Est-il
gourmand en ressources?

Enfin, pour les sauvegarde, comment ça se passe avec Postgresql?

Merci pour vos conseil.
Thibaut

Bonjour,

Thibaut LE LEVIER a écrit :
> [...]
> J'aurai bien aimé être présent lors des RMLL mais le programme ne me
> plaisait que moyennement.

Pourtant, il y avait une conférence et plein d'ateliers sur PostgreSQL :)

> [...]
> J'en viens donc à me pauser quelques questions auxquelles je ne peux pas
> encore répondre seul:
>
> Pourquoi PostgreSQL plutôt que MySQL? (je suppose que ça reviens presque
> au même pourquoi Oracle, hormis la question du prix et de la licence)
>

Le document « Pourquoi préférer PostgreSQL à MySQL »
(http://www.postgresqlfr.org/?q=node/1432) me semble un bon début pour
des réponses à cette question. Ne connaissant pas MySQL plus que ça, je
n'irais pas plus loin.

> De la même manière quelle volume peut supporter Postgresql? Est-il
> gourmand en ressources?
>

Ça va du méga à plusieurs téra (lire le retour d'expérience de Météo
France sur http://www.postgresqlfr.org/?q=node/1538)

> Enfin, pour les sauvegarde, comment ça se passe avec Postgresql?
>

Le mieux est de lire la documentation :
http://docs.postgresqlfr.org/8.3/backup.html

Bon courage dans la suite de votre étude :)

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

>
> > De la même manière quelle volume peut supporter Postgresql? Est-il
> > gourmand en ressources?
>
> Ça va du méga à plusieurs téra (lire le retour d'expérience de Météo
> France sur http://www.postgresqlfr.org/?q=node/1538)
>

À ce sujet, on peut également citer le système Everest développé en interne
par Yahoo! qui est un fork de PostgreSQL et qui héberge actuellement 2
petabytes de données.

http://www.flickr.com/photos/gavinmroy/2520304654/
http://www.postgresqlfr.org/?q=node/1648

--
damien clochard
http://dalibo.org | http://dalibo.com

damien clochard a écrit :
>>> De la même manière quelle volume peut supporter Postgresql? Est-il
>>> gourmand en ressources?
>> Ça va du méga à plusieurs téra (lire le retour d'expérience de Météo
>> France sur http://www.postgresqlfr.org/?q=node/1538)
>>
>
> À ce sujet, on peut également citer le système Everest développé en interne
> par Yahoo! qui est un fork de PostgreSQL et qui héberge actuellement 2
> petabytes de données.
>
> http://www.flickr.com/photos/gavinmroy/2520304654/
> http://www.postgresqlfr.org/?q=node/1648
>

Yep, j'ai voulu en parler mais me suis abstenu. Tout simplement parce
qu'il faut bien voir que c'est une version fortement modifiée de PostgreSQL.

Personne n'a (actuellement) fait un retour sur l'utilisation d'une base
PostgreSQL de même un seul Po utilisant les sources non modifiées de
PostgreSQL.

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

Hop,

> Personne n'a (actuellement) fait un retour sur l'utilisation d'une base
> PostgreSQL de même un seul Po utilisant les sources non modifiées de
> PostgreSQL.

Ce qui ne veut pas dire qu'elles n'existent pas...

;-)

--
Jean-Paul Argudo
www.PostgreSQLFr.org
www.Dalibo.com

Jean-Paul Argudo a écrit :
> Hop,
>
>> Personne n'a (actuellement) fait un retour sur l'utilisation d'une base
>> PostgreSQL de même un seul Po utilisant les sources non modifiées de
>> PostgreSQL.
>
> Ce qui ne veut pas dire qu'elles n'existent pas...
>
> ;-)
>

Je ne crois que ce que je vois :)

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

On Sun, 27 Jul 2008 13:50:49 +0200
Thibaut LE LEVIER <thibaut(at)lelevier(dot)fr> wrote:

> Bonjour à tous,
>
> Je suis la liste depuis quelques mois maintenant mais ceci est mon
> premier message alors je vais vite fait me présenter:
> Je me nomme Thibaut, je suis étudiant en informatique à supinfo (oué je
> sais moyen) sur le récent site de Limoges et sinon je vis sur Sarlat en
> Dordogne.
> Je suis intéresse par tout ce qui est base de donnée et j'essaye
> actuellement d'avoir des notions de bases sur les différents système
> utilisées (MySQL, Oracle, Postgresql biensur, mais aussi SQL server, DB2
> et autres...)
>
> J'aurai bien aimé être présent lors des RMLL mais le programme ne me
> plaisait que moyennement.
> Et je ne pourrai malheureusement pas être présent lors de la PGDay car
> je serai en stage en Eure-et-Loire à coder des script SQL et PL/SQL sur
> les serveurs Oracle de chez MMA.
>
> Je me suis donc intéressé à Postgresql car après quelques lectures sur
> le net, j'ai vu que les performances de celui si pouvais rivaliser avec
> Oracle et sans doute donc dépasser les limitations de MySQL que je
> rencontre régulièrement en codant quelques sites relativement volumineux
> en donnés.
>
> J'en viens donc à me pauser quelques questions auxquelles je ne peux pas
> encore répondre seul:
>
> Pourquoi PostgreSQL plutôt que MySQL? (je suppose que ça reviens presque
> au même pourquoi Oracle, hormis la question du prix et de la licence)
>
> De la même manière quelle volume peut supporter Postgresql? Est-il
> gourmand en ressources?
>
> Enfin, pour les sauvegarde, comment ça se passe avec Postgresql?
>
> Merci pour vos conseil.
> Thibaut
>
>
> --
> Sent via pgsql-fr-generale mailing list (pgsql-fr-generale(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-fr-generale
>
Bonjour,

Ma modeste contribution à 2 cts (d'euro).
Il y a quelques années, sans connaitre grand chose aux SGBDs, j'ai voulu en utiliser un pour remplacer le C-ISAM.
- Postgres ou MySQL : la doc a été déterminante, je ne sais si MySQL a fait des progrés mais c'était pas facile a trouver.
Ensuite, la license, celle de MySQL était "ésotérique" ; la Berkeley est claire.
Les performances de MySQL étaient données comme meilleures à l'époque (1999 ?) mais postgrés a fait des progrés depuis et j'ai toujours était époustouflé par les résultats.
- Oracle, je n'y ai même pas pensé pour une question de prix et à ma connaissance c'est un descendant de Ingres comme Postgres.
J'avais aussi reçu un coffret d'IBM avec DB2, mais je n'ai pas essayé.
- Sauvegardes : pg_dump et pg_restore permettent de faire à peu près n'importe quoi.
- Volumes : les bases dont j'ai à m'occuper ne dépassent pas les 6GO, donc ... !
--
Alain <eurlix(dot)alain(at)free(dot)fr>

Bonsoir à tous et tout d'abord merci pour ces précisions.

Je vais prendre le temps de jeter un œil aux liens que vous m'avez donner.

En effet 2 peta c'est plutôt impressionnant.
Même 6go d'ailleurs.

Par la même occasion il me vient donc une question: niveau hardware ça
réclame quoi?
beaucoup de ram? est-ce que le processeur est sollicité? du cache sur
les disques?
Quel est l'idéal?

Je pense que je ne vais pas me mettre à migrer tout les sites que j'ai
réaliser, mais je pense que le prochain "gros site" que je vais réaliser
me permettra de me familiariser avec PostGreSQL.

Biensur je ne parle là que d'un coté un peut webdev mais je suppose que
le PHP n'est pas le seul langage facilement couplé avec PG. Juste pour
sondage, qu'est-ce que vous utilisez? pour quel type d'applications?

PG m'intéresse de plus en plus :)

Encore merci

Thibaut

Thibaut LE LEVIER a écrit :
> Bonsoir à tous et tout d'abord merci pour ces précisions.
>
> Je vais prendre le temps de jeter un œil aux liens que vous m'avez donner.
>
> En effet 2 peta c'est plutôt impressionnant.
> Même 6go d'ailleurs.
>

Sans vouloir se la jouer, 6 Go n'est rien pour PostgreSQL :)

> Par la même occasion il me vient donc une question: niveau hardware ça
> réclame quoi?

Je dirais que ça dépend énormément de l'utilisation qui est faite de la
base.

> beaucoup de ram? est-ce que le processeur est sollicité? du cache sur
> les disques?
> Quel est l'idéal?
>

Sans plus de contexte, c'est difficile de le dire. PostgreSQL utilise
peu les CPU, il vaut mieux dépenser son budget sur la RAM et les
disques. Une configuration un peu habituelle pour des bases de plusieurs
Giga, avec plus de 50 connexions simultanées, est un serveur bi Xéon, 4
Go de RAM, et des disques rapides (donc généralement SCSI) de
préférence. C'est juste un exemple. On peut faire avec moins évidemment.
Tout dépend du contexte : de l'utilisation de PostgreSQL par les clients
connectés, de la configuration de PostgreSQL, etc.

> Je pense que je ne vais pas me mettre à migrer tout les sites que j'ai
> réaliser, mais je pense que le prochain "gros site" que je vais réaliser
> me permettra de me familiariser avec PostGreSQL.
>
> Biensur je ne parle là que d'un coté un peut webdev mais je suppose que
> le PHP n'est pas le seul langage facilement couplé avec PG. Juste pour
> sondage, qu'est-ce que vous utilisez? pour quel type d'applications?
>

PHP en ce qui me concerne. Mais tous les autres langages sont bienvenus,
que ce soit du C, du Perl, du python, du ruby, etc.

> PG m'intéresse de plus en plus :)
>

Excellent :)

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

Thibaut LE LEVIER a écrit :
> Bonsoir à tous et tout d'abord merci pour ces précisions.
>
> Je vais prendre le temps de jeter un œil aux liens que vous m'avez donner.
>
> En effet 2 peta c'est plutôt impressionnant.
> Même 6go d'ailleurs.
>
> Par la même occasion il me vient donc une question: niveau hardware ça
> réclame quoi?
> beaucoup de ram? est-ce que le processeur est sollicité? du cache sur
> les disques?
> Quel est l'idéal?

La mémoire est naturellement ce que je regarde en premier. Car plus
la base peut y tenir, meilleur seront les performances.
(http://stephane.bpf.st/si/bdd/pg/memuseage)

L'organisation des données sur disque n'est pas à négliger. Je
préfère par exemple créer plusieurs axes en RAID-1 puis utiliser les
tablespaces pour répartir les données selon leur caractère. Cela permet
aussi de faire un choix entre capacité et rapidité. Exemple du SATA2
pour la capacité (ex: données en ajout) et du SAS(SCSI) pour les
indexes. Les plus riches feront du FibreChannel.

Une fois le matériel choisi, il faut naturellement s'atteler à
l'optimisation des paramètres de PostgreSQL. La doc en ligne donne de
nombreux conseils.

> Je pense que je ne vais pas me mettre à migrer tout les sites que j'ai
> réaliser, mais je pense que le prochain "gros site" que je vais réaliser
> me permettra de me familiariser avec PostGreSQL.

Mise en garde contre les risques d'addiction au produit: L'usage
prolongé de PostgreSQL peut rendre l'utilisateur dépendant d'un certain
niveau d'exigence, tant techniques que fonctionnelles. Un effet
secondaire connu est la rigolite (ou au contraire la tristesse chez
certain individu) aigu à la simple évocation de produits prétendument
"concurrent".

> Biensur je ne parle là que d'un coté un peut webdev mais je suppose que
> le PHP n'est pas le seul langage facilement couplé avec PG. Juste pour
> sondage, qu'est-ce que vous utilisez? pour quel type d'applications?

Python, pour tout (ou presque) ;-)

Stéphane Bunel.

On 29-07-2008, Thibaut LE LEVIER wrote:
> Bonsoir à tous et tout d'abord merci pour ces précisions.
>
> Je vais prendre le temps de jeter un œil aux liens que vous m'avez donner.
>
> En effet 2 peta c'est plutôt impressionnant.
> Même 6go d'ailleurs.
>
> Par la même occasion il me vient donc une question: niveau hardware ça
> réclame quoi?

C'est bien sur relatif aux données que tu veux gérer, ou plutôt à la
façon dont tu veux y accéder... Mais on peut très bien tourner avec
trois fois rien, j'ai un serveur virtuel avec 256mo de ram sur lequel
tourne un jeu en ligne, un autre avec 512mo et une quinzaine de bases...

> beaucoup de ram? est-ce que le processeur est sollicité? du cache sur
> les disques?
> Quel est l'idéal?
>
>
> Je pense que je ne vais pas me mettre à migrer tout les sites que j'ai
> réaliser, mais je pense que le prochain "gros site" que je vais réaliser
> me permettra de me familiariser avec PostGreSQL.

C'est quand même beaucoup plus pratique d'utiliser toujours le même
moteur afin d'amortir son étude (pas toujours trivial). Je te
conseillerai plutôt au contraire de migrer quelques sites simples que tu
connais bien pour te familiariser avec la bête.

>
> Biensur je ne parle là que d'un coté un peut webdev mais je suppose que
> le PHP n'est pas le seul langage facilement couplé avec PG. Juste pour
> sondage, qu'est-ce que vous utilisez? pour quel type d'applications?

python, principalement de la gestion d'entreprise.

>
> PG m'intéresse de plus en plus :)
>
> Encore merci
>
> Thibaut
>
>

--
William Dodé - http://flibuste.net
Informaticien indépendant

Stéphane Bunel a écrit :
>> Je pense que je ne vais pas me mettre à migrer tout les sites que
>> j'ai réaliser, mais je pense que le prochain "gros site" que je vais
>> réaliser me permettra de me familiariser avec PostGreSQL.
>
> Mise en garde contre les risques d'addiction au produit: L'usage
> prolongé de PostgreSQL peut rendre l'utilisateur dépendant d'un
> certain niveau d'exigence, tant techniques que fonctionnelles. Un
> effet secondaire connu est la rigolite (ou au contraire la tristesse
> chez certain individu) aigu à la simple évocation de produits
> prétendument "concurrent".

:)

C'est très vrai, ça. Faut faire attention, quand même, faudrait pas que
ça devienne pathologique ...

--
Sébastien

On 29-07-2008, Thibaut LE LEVIER wrote:
> Je pense que je ne vais pas me mettre à migrer tout les sites que j'ai
> réaliser

Tien, pour la petite anecdote, quand j'ai migré mon premier site de
mysql a postgresql, ça a planté rapidement : interdiction d'écrire la
valeur, champ trop court. J'essaye à nouveau avec mysql, là ça marche,
le champ était tronqué silencieusement ! J'ai migré tous mes sites
depuis en faisant attention à bien vérifier mes tailles de champs en
amont :-)
Avec PG on retrouve beaucoup moins ce côté imprévisible.

--
William Dodé - http://flibuste.net
Informaticien indépendant

William Dode a écrit :
> On 29-07-2008, Thibaut LE LEVIER wrote:
>> Je pense que je ne vais pas me mettre à migrer tout les sites que j'ai
>> réaliser
>
> Tien, pour la petite anecdote, quand j'ai migré mon premier site de
> mysql a postgresql, ça a planté rapidement : interdiction d'écrire la
> valeur, champ trop court. J'essaye à nouveau avec mysql, là ça marche,
> le champ était tronqué silencieusement ! J'ai migré tous mes sites
> depuis en faisant attention à bien vérifier mes tailles de champs en
> amont :-)

Pour une telle migration, je prends soin de retoucher le modèle pour
transformer, par exemple, tout VARCHAR(n) ou CHAR(n) en TEXT. PostgreSQL
n'a, lui, aucun problème d'indexation avec ce type.

Si une limite en longueur de champs est nécessaire, je préfère
utiliser une contrainte de type CHECK[1], ou un règle[2] (RULE), car la
limite vient souvent du fonctionnel et tant à évoluer avec le temps.
C'est un choix de conception, il n'y a là rien de technique en revanche.

> Avec PG on retrouve beaucoup moins ce côté imprévisible.

D'une manière générale je dirais que PostgreSQL réclame à être plus
conscient de ce que l'on fait. En retour cela développe les compétences.
Un peut moins "facile" au début lorsque venant de MySQL, car s'il faut
désapprendre légèrement pour réapprendre la peine est vite récompensée.
C'est mon avis, tout personnel ;)

Stéphane Bunel.

[1] http://www.postgresql.org/docs/8.3/static/ddl-constraints.html
[2] http://www.postgresql.org/docs/current/static/rules-update.html

On 29-07-2008, Stéphane Bunel wrote:
> William Dode a écrit :
>> On 29-07-2008, Thibaut LE LEVIER wrote:
>>> Je pense que je ne vais pas me mettre à migrer tout les sites que j'ai
>>> réaliser
>>
>> Tien, pour la petite anecdote, quand j'ai migré mon premier site de
>> mysql a postgresql, ça a planté rapidement : interdiction d'écrire la
>> valeur, champ trop court. J'essaye à nouveau avec mysql, là ça marche,
>> le champ était tronqué silencieusement ! J'ai migré tous mes sites
>> depuis en faisant attention à bien vérifier mes tailles de champs en
>> amont :-)
>
> Pour une telle migration, je prends soin de retoucher le modèle pour
> transformer, par exemple, tout VARCHAR(n) ou CHAR(n) en TEXT. PostgreSQL
> n'a, lui, aucun problème d'indexation avec ce type.
>
> Si une limite en longueur de champs est nécessaire, je préfère
> utiliser une contrainte de type CHECK[1], ou un règle[2] (RULE), car la
> limite vient souvent du fonctionnel et tant à évoluer avec le temps.
> C'est un choix de conception, il n'y a là rien de technique en revanche.

C'est bon à savoir ça, moi qui ai encore un vieux réflexe de culpabilité
à chaque fois que j'utilise un champ TEXT...

--
William Dodé - http://flibuste.net
Informaticien indépendant

Bonjour à tous

Sébastien Lardière wrote:
> Stéphane Bunel a écrit :
>>> Je pense que je ne vais pas me mettre à migrer tout les sites que
>>> j'ai réaliser, mais je pense que le prochain "gros site" que je vais
>>> réaliser me permettra de me familiariser avec PostGreSQL.
>>
>> Mise en garde contre les risques d'addiction au produit: L'usage
>> prolongé de PostgreSQL peut rendre l'utilisateur dépendant d'un
>> certain niveau d'exigence, tant techniques que fonctionnelles. Un
>> effet secondaire connu est la rigolite (ou au contraire la tristesse
>> chez certain individu) aigu à la simple évocation de produits
>> prétendument "concurrent".
>
> :)
>
> C'est très vrai, ça. Faut faire attention, quand même, faudrait pas
> que ça devienne pathologique ...
>
Je crois que ça commence :)
Juste une dernière question sur une partie un peux plus "hardware"
32 ou 64bits? est-ce que ça change quelque chose sur la capacité de
connections simultanées de PG?
J'ai un vieux Proliant avec 2 Pentium 667mhz, 2go de SDRam ECC et 4
Disque SCSI en Raid5. Je pense l'utiliser pour mes tests mais d'après
vous, pour combien de connections simultanée il conviendrai? 20? 30?

Merci
Thibaut

Thibaut LE LEVIER a écrit :
> Bonjour à tous
>
> Sébastien Lardière wrote:
>> Stéphane Bunel a écrit :
>>>> Je pense que je ne vais pas me mettre à migrer tout les sites que
>>>> j'ai réaliser, mais je pense que le prochain "gros site" que je vais
>>>> réaliser me permettra de me familiariser avec PostGreSQL.
>>>
>>> Mise en garde contre les risques d'addiction au produit: L'usage
>>> prolongé de PostgreSQL peut rendre l'utilisateur dépendant d'un
>>> certain niveau d'exigence, tant techniques que fonctionnelles. Un
>>> effet secondaire connu est la rigolite (ou au contraire la tristesse
>>> chez certain individu) aigu à la simple évocation de produits
>>> prétendument "concurrent".
>>
>> :)
>>
>> C'est très vrai, ça. Faut faire attention, quand même, faudrait pas
>> que ça devienne pathologique ...
>>
> Je crois que ça commence :)
> Juste une dernière question sur une partie un peux plus "hardware"
> 32 ou 64bits?

À ma connaissance, aucune importance.

> est-ce que ça change quelque chose sur la capacité de
> connections simultanées de PG?

Non. Je ne vois pas en quoi les deux seraient liés ?

> J'ai un vieux Proliant avec 2 Pentium 667mhz, 2go de SDRam ECC et 4
> Disque SCSI en Raid5. Je pense l'utiliser pour mes tests mais d'après
> vous, pour combien de connections simultanée il conviendrai? 20? 30?
>

Facilement 1000 s'ils font tous seulement "SELECT true" une seule fois
par jour :)

Ce que je veux dire par ce trait d'esprit un peu pourri, c'est qu'on ne
peut pas te répondre. Par défaut, le fichier de config permet
généralement 100 connexions simultanées. Maintenant, le nombre de
connexions *réelles* dépend surtout de la façon dont se comportent les
applications qui se connecteront au serveur (ie nombre de
transactions/seconde, ratio requêtes de lecture/requêtes d'écriture), etc.)

Petite astuce en passant : oublie le RAID5, unanimement décrié pour sa
lenteur en écriture.

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

Guillaume Lelarge a écrit :
> Juste une dernière question sur une partie un peux plus "hardware"
> 32 ou 64bits?
>
>
> À ma connaissance, aucune importance.
>
>
Pas tout à fait quand même. Au delà de 4 Go de RAM il vaut mieux
privilégier le 64 bits. Mais ceci dépend énormément de l'OS sous-jacent...
> Petite astuce en passant : oublie le RAID5, unanimement décrié pour sa
> lenteur en écriture.
>
Je confirme, rien ne vaut le RAID 10 !

--
Christophe Garault

Christophe Garault a écrit :
> Guillaume Lelarge a écrit :
>> Juste une dernière question sur une partie un peux plus "hardware"
>> 32 ou 64bits?
>>
>> À ma connaissance, aucune importance.
>>
>>
> Pas tout à fait quand même. Au delà de 4 Go de RAM il vaut mieux
> privilégier le 64 bits. Mais ceci dépend énormément de l'OS sous-jacent...

La question immédiate est pourquoi ? et en quoi l'OS joue dans ce
domaine ? et enfin, quel OS préconises-tu pour le coup du 64 bits ?

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

Guillaume Lelarge a écrit :
> La question immédiate est pourquoi ? et en quoi l'OS joue dans ce
> domaine ? et enfin, quel OS préconises-tu pour le coup du 64 bits ?
>
Et bien parce que les OS 32 bits gèrent très mal voire pas du tout la
mémoire au delà de 4 Go (2^32). Sur un windows 32 bits c'est déjà la
mort au delà de 3Go...
J'ai un peu honte de l'avouer ici mais dans le domaine des télécoms où
j'officie il y a hélas très peu de PostgreSQL; mon expérience se limite
donc à des produits proprio. Mais que ce soit sur du Windows 2003-64 ,
Debian Etch ou sur du RHEL 64 je n'ai pas rencontré le moindre problème.
A noter également que la version de l'OS (ou les paramètres de compil du
kernel) est importante pour le nombre maximum de processeurs gérés.

--
Christophe Garault

Christophe Garault a écrit :
> Guillaume Lelarge a écrit :
>> La question immédiate est pourquoi ? et en quoi l'OS joue dans ce
>> domaine ? et enfin, quel OS préconises-tu pour le coup du 64 bits ?
>>
> Et bien parce que les OS 32 bits gèrent très mal voire pas du tout la
> mémoire au delà de 4 Go (2^32). Sur un windows 32 bits c'est déjà la
> mort au delà de 3Go...
> J'ai un peu honte de l'avouer ici mais dans le domaine des télécoms où
> j'officie il y a hélas très peu de PostgreSQL; mon expérience se
> limite donc à des produits proprio. Mais que ce soit sur du Windows
> 2003-64 , Debian Etch ou sur du RHEL 64 je n'ai pas rencontré le
> moindre problème.
> A noter également que la version de l'OS (ou les paramètres de compil
> du kernel) est importante pour le nombre maximum de processeurs gérés.
>
Sous Windows peut-être, mais à ma connaissance, les noyaux comme Linux
savent gérer correctement la mémoire au-dela de 4Go, même en 32bits.

Il n'est de toute façon pas recommandé de mettre PostgreSQL en
production avec Windows. Sauf contrainte particulière, prenez un système
de type Unix.

--
Sébastien Lardière

Sébastien Lardière a écrit :
>
> Sous Windows peut-être, mais à ma connaissance, les noyaux comme Linux
> savent gérer correctement la mémoire au-dela de 4Go, même en 32bits.
>

Oui tu as tout à fait raison, avec cependant la réserve d'avoir un noyau
compilé avec le paramètre idoine.
Ca reste néanmoins une sorte de mapping si mes souvenirs sont bons, donc
à éviter si possible.
De toutes façons tous les processeurs actuels étant 64 bits il n'y a
plus guère de raison de faire tourner un serveur avec un noyau 32 bits.
(c'est autre chose pour une station de travail ok).

--
Christophe Garault

Bonsoir tout le monde :)

Merci pour ses conseils encore une fois, je pense pouvoir me lancer dans
postgre très prochainement :)

J'ai repérer chez un éditeur que j'aime bien (malheureusement fermé en
france) ce livre:
http://www.amazon.fr/gp/product/toc/1565928466/ref=dp_toc?ie=UTF8&n=301061

qu'en pensez vous?

Merci
Bonne fin de weekend

Thibaut

Thibaut LE LEVIER a écrit :
> [...]
> Merci pour ses conseils encore une fois, je pense pouvoir me lancer dans
> postgre très prochainement :)
>
> J'ai repérer chez un éditeur que j'aime bien (malheureusement fermé en
> france) ce livre:
> http://www.amazon.fr/gp/product/toc/1565928466/ref=dp_toc?ie=UTF8&n=301061
>
> qu'en pensez vous?
>

En un seul mot ? obsolète.

Il date de janvier 2002, donc il couvre au mieux la 7.2. Je l'ai lu il y
a un bon moment, et je l'ai trouvé intéressant. Maintenant, il est
complètement dépassé.

Fonce sur http://www.postgresql.org/docs/books/ pour une liste de livres
sur PostgreSQL. Pour débuter, le livre de Sébastien est très bien.
Ensuite, il n'y a à ma connaissance que la doc. En tout cas, je ne
connais aucun livre qui aille plus loin que la documentation officielle
(qui n'est pourtant pas complète).

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

Le Sun, 03 Aug 2008 01:43:02 +0200, Guillaume Lelarge <guillaume(at)lelarge(dot)info> a écrit :

> [...] En tout cas, je ne
> connais aucun livre qui aille plus loin que la documentation officielle
> (qui n'est pourtant pas complète).

Je rebondis sur cette dernière remarque : je trouve la documentation de PostgreSQL super
bien, claire, bien organisée, et justement plutôt "complète".
Qu'est-ce qu'il manque dedans pour que tu la considère comme complète ?

Merci,
Jonathan

Jonathan Ballet a écrit :
> Le Sun, 03 Aug 2008 01:43:02 +0200, Guillaume Lelarge <guillaume(at)lelarge(dot)info> a écrit :
>
>> [...] En tout cas, je ne
>> connais aucun livre qui aille plus loin que la documentation officielle
>> (qui n'est pourtant pas complète).
>
> Je rebondis sur cette dernière remarque : je trouve la documentation de PostgreSQL super
> bien, claire, bien organisée, et justement plutôt "complète".
> Qu'est-ce qu'il manque dedans pour que tu la considère comme complète ?
>

Une description de la fonctionnalité HOT (dont l'absence dans la
documentation est voulue par Tom Lane, bien que critiquée par certains
développeurs), une description des Hints Bits, une liste des noeuds d'un
plan de requêtes avec une explication des algorithmes utilisés, etc. Des
informations plutôt haut niveau en fait. En lisant le code source de
PostgreSQL, on a quantité d'informations supplémentaires. Rien qu'en
lisant les fichiers README par exemple, on apprend énormément de choses.
Et je ne parle même pas du wiki de PostgreSQL.

Je suis d'accord avec toi qu'elle est très complète. J'en suis bien
conscient, je la connais plutôt bien, et les 1400 pages sont la preuve
que beaucoup de choses est documenté. Mais il y manque des éléments
importants.

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

Bonjour à tous et encore une fois désolé pour cette réponse tardive

j'ai commencé aujourd'hui à développer mon premier site 'fonctionnel' en
php/postgresql et je dois dire que je trouve ça plutôt agréable :)

j'ai eu l'impression d'aller très vite pour la partie base de donnée, je
n'ai pas eu à revenir une seule fois sur mes accès dans php et tout à
fonctionner du premier coup!

le plus impressionnant a été, je crois, la facilité de placer des clé
étrangères avec pgadmin 3, je crois même qu'avec mysql je me serai
contenter d'aller chercher mes donnée avec php et je n'aurai pas mi de
FK (comme le font la plupart des développeurs que je connaît)

bref plutôt bien parti :)

Merci pour vos conseils :)

Thibaut

Thibaut LE LEVIER a écrit :
> [...]
> j'ai commencé aujourd'hui à développer mon premier site 'fonctionnel' en
> php/postgresql et je dois dire que je trouve ça plutôt agréable :)
>
> j'ai eu l'impression d'aller très vite pour la partie base de donnée, je
> n'ai pas eu à revenir une seule fois sur mes accès dans php et tout à
> fonctionner du premier coup!
>
> le plus impressionnant a été, je crois, la facilité de placer des clé
> étrangères avec pgadmin 3, je crois même qu'avec mysql je me serai
> contenter d'aller chercher mes donnée avec php et je n'aurai pas mi de
> FK (comme le font la plupart des développeurs que je connaît)
>
> bref plutôt bien parti :)
>

Félicitations :)

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com