Newsgroup: it.comp.os.linux.software
Titolo: PostgreSQL

Ho la possibilita' di avviare un progetto internet basato su PHP e 
PostgreSQL.
Stranamente pero' il tipo dell'hosting me lo ha sconsigliato perche per 
sua "esperienza personale" questo db e' lento e addirittura instabile 
costringendolo a riavviare il servizio ogni 3-4 giorni.
La cosa mi puzza anche perche' in tanti mi hanno consigliato questo db 
decantandone la qualita' (e leggendo la documentazione devo dire che mi 
piace sempre di piu').
Sara' che il tipo si e' fumato qualcosa di *molto buono* ?
Ciaps
-- 
Neo & Rotella (CBR 600 F Rosso Blu) da Campi Bisenzio
/************************************************
ICQ #42292922
Webmaster di:
www.thezion.net
 (now PHP Powered)
Registered Linux User #277621 - 
http://counter.li.org
************************************************/

 piace sempre di piu').
Sulla stabilita', ti posso dire che noi abbiamo in hosting un sito che usa
Postgres, e non ha avuto un solo riavvio in oltre 6 mesi, quindi sono
sorpreso quanto te.
Sulle prestazioni, tutto e' ovviamente relativo. Certo qualche mese fa mi
e' capitato di avere lo stesso database portato da Informix a Postgres, e
di doverci eseguire sopra uno script "di pulizia"; su Informix ha finito
in 2 ore, su Postgres in oltre 12, su hardware identico; ma non vale come
benchmark, se non altro perche' il database Informix era *estremamente*
ottimizzato, quello di Postgres era portato abbastanza alla carlona (e'
una storia lunga), e comunque stiamo parlando di un database che si
prendeva oltre 4 GB
Eugenio
-- 
Conservative, n.:
        One who admires radicals centuries after they're dead.

 Sara' che il tipo si e' fumato qualcosa di *molto buono* ? Ciaps
 
Io lo uso per l'autenticazione degli utenti e lo riavvio solo in 2 casi:
1)reboot del server (per aggiornamento del kernel)
2)upgrade del database
(Ho 39 database sul server...)
Concludendo: si è fumato una piantagione di canapa indiana!
-- 
Roberto Tagliaferri<-> r.tagliaferri@(forse)
tosnet.it
	Sentito da una programmatrice:
	"Ma vi capita mai nella vita reale, tipo mentre
	rifate il letto di dire 'Ho sbagliato, pigio ctrl-Z'?"

Sara' che il tipo si e' fumato qualcosa di *molto buono* ?
sara` che banalmente non e` capace di usarlo.
-- 
Maurizio - Tannoiser - Lemmo
Founder Member of ERLUG (Emilia Romagna Linux User Group)
http://erlug.linux.it

 Sara' che il tipo si e' fumato qualcosa di *molto buono* ?
No, probabilmente pero' si è bevuto la propaganda anti-postgres sparsa 
in giro per la rete dagli zeloti di MySQL ;-)
Scherziapparte: sull'instabile non scherziamo neanche, credo che ancora 
stia girando un'applicazione PHP/Postgresql che ho messo su nel 1997, e 
non è stata mai (volontariamente ;-), ENEL a parte insomma) riavviata. 
Oltretutto con le release dell'epoca e senza nessuna ottimizzazione 
particolare :-)
Dal punto di vista prestazionale invece le release un po' anzianotte di 
Postgres erano effettivamente lente, e può anche darsi che la persona si 
sia scottata con una di quelle. Dalla 7.1 in poi la situazione è 
DECISAMENTE migliorata... restano pero' dei problemi che anche se sono 
un fan di Postgres mi sento in dovere di segnalare:
-Occhio al consumo della memoria al crescere degli accessi concorrenti: 
PHP non fa un connection pooling, ergo per x navigatori hai minimo x 
connessioni al DB... ognuna delle quali consuma un tot di RAM. Di 
default Postgres è configurato per accettare un max di 32 connessioni 
temporanee: su un sito di traffico più che modesto non bastano. Al 
crescere del traffico, può essere necessario dell'HW piuttosto robusto.
-Occhio al VACUUM: sotto postgresql il lavoro di "pulizia" delle tabelle 
e aggiornamento delle statistiche dell'ottimizzatore, indispensabile per 
garantire buone prestazioni, viene lanciato a comando dall'utilizzatore 
(con il vacuum, per l'appunto). Durante questo processo, che può 
richiedere un tempo non trascurabile, il DB diventa poco responsivo 
(praticamente si pianta finchè non ha finito...). Quasi tutti gestiscono 
il problema lanciando un vacuum al giorno nottetempo, ma secondo molti 
detrattori è pur sempre un "buco" nell'availability del sito.
-Occhio alle ottimizzazioni: le prestazioni di Postgresql possono 
variare molto al variare delle opzioni di configurazione... (fsync, 
dimensione dei buffer di RAM, ottimizzatore genetico presente/assente, 
eccetera). E' possibile che un'installazione "out of the box" non sia la 
migliore possibile per il lavoro che devi fare.
Per ogni altra info chiedi pure ;-)
Ciao!
-- 
Fabrizio "Hermooz" Ermini



Sono stati eseguiti dei test, i link dei quali si possono trovare sul sito
di postgresql, nel quale postgresql superava in prestazioni mostri quali
oracle, informix, interbase e mysql. Il test e' stato eseguito secondo
delle rigide specifiche, e e misurava la scalabilita' di  in base al
numero di transazioni che la numero di utenti contemporanei (da 0 a 100).
Quindi credo che si', sia stata solo una questione di otimizzazione del
database.
ciao, Michele

 Ciaps
Hai chiesto quale versione usa? E arrivato alla 7.3 ... ;-)
ciao, Michele

.
[...]       
 
  ora il primo link apre un motore di ricerca per directory
  il secondo apre una pagina per l'acquisto on-line di VIAGRA
  (di benchmark si parla ? ...)   
-- 
senza lilleri non si lallera

   (di benchmark si parla ? ...)
I postgreSql how-to, a meno di recenti aggiornamenti, non sono
disponibili, per cui quello che hai potrebbe essere datato.
I test effettuati erano "ANSI SQL Standard Scalable And Portable" (AS3AP)
benchmark e "Transaction Processing Council's" TPC-C test.
Sul sito ufficiale non sono piu' riuscito a trovare i link ai test (sono
stati eseguiti nel 2000), ma puoi trovare l'informazione a questo link:
http://www.serverwatch.com/news/article.php/10824_1126981_Ext
ciao, Michele

 particolare :-)
Io utilizzo una vecchia versione di postgresql, precisamente la 6.5, per
un grosso DB aziendale con carichi di lavoro piuttosto alti e una mole
di dati che si aggira sulle 50 tabelle, con alcune di queste che
arrivano anche a 4 milioni di record.
E` un sistema H24, perchè, oltre a fare tante altre cose, raccoglie dati
da un impianto di produzione per generare una quantità mostruosa di
report (in PHP4 + GD).
La stabilità è indiscutibile, ma ogni tanto qualche scherzetto me lo ha
fatto (p. es., spesso una INSERT INTO ... SELECT ... mi ha fa crashare
il backend quando non riuscivano certi cast impliciti). Ho avuto,
invece, un problema fastidioso che non sono riusciuto a risolvere: se
faccio lo shutdown *pulito* del DB gli indici si corrompono! Sempre! Per
ovviare devo eseguire uno script di rebuild degli indici ad ogni
shutdown/restart del db, ma una volta mi è capitato di dimenticarmene ed
è successo un po di casino (perchè saltano i lookup tramite indice). Per
fortuna gli shutdown sono eventi rarissimi (l'ultimo a giugno per
manutenzione HW) e quindi il problema non pesa più di tanto. Cosa ancora
più strana è che il problema sembra verificarsi *solo* su due Compaq
Proliant (che formano il cluster di produzione :-|). Lo stesso DB
copiato su un HP Netserver o su un qualsiasi altro PC non da questo
problema. Inoltre tempo fa ho provato a ricreare il DB da zero (sempre
sul Compaq), ma il problema è rimasto. 
Ho letto di problemi di corruzione di indici nella 6.x, infatti vorrei
passare almeno alla 7.2.x, portando l'attuale Potato a Woody, ma
il cliente (e il mio capo) non me lo permetteranno mai...
-- 
s/invalid.invalid/
libero.it/
spam -> 
da...@tin.it

 il cliente (e il mio capo) non me lo permetteranno mai...
La colpa ad ogni modo e' loro non di postgresql ...
Gli stessi sviluppatori hanno detto che la prima versione veramente
stabile e' stata la 7.0.0... ora siamo arrivati 7.3.0 ;-)
ciao, Michele