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

Vorrei trasferire un mio database da Microsoft Access2 a Postgres.
Uso tabelle di dati di borsa con circa 500.000 records su 3 campi.
Dalle prime prove il select e' molto lento e gia' il select con order un 
disastro (i tempi sono circa 10 volte quelli richiesti dal vecchio 
Access 2 usato sino ad ora).
E' normale?
Esistono ottimizzazioni che mi sono sfuggite?
Lavoro con un AMDK6450 e 128 M di RAM e postgres e' l' ultima versione 
allegata al RedHat6.2 che ho appena installato.
Sto provando Mysql e si presenta estremamente piu' veloce.
Datemi un consiglio per favore: in queste condizioni e' meglio che 
non perda piu' tempo con postgres e punti su mysql od altri?
Daniele 

 non perda piu' tempo con postgres e punti su mysql od altri?
MySQL e` un DB molto gettonato perche` veloce, ma allo stesso tempo e` piu`
limitato di postgres.
-- 
  /Kinkie
Se sulla scatola c'e` scritto "Per windows 95 e superiori", dovrebbe
funzionare sotto Linux, vero?

non perda piu' tempo con postgres e punti su mysql od altri?
Se non ti servono transazioni, foreign keys e similari, forse non
sarebbe male preferire MySQL.
Leonardo
".signature": bad command or file name

Esistono ottimizzazioni che mi sono sfuggite?
Hai usato gli indici?
ciao Michele


Nel database vengono costruite quotidianamente molte tabelle di 
performances e di confronto dei dati con diverse centinaia di migliaia 
di records e le analisi sono sotto forma di grafici (OLE).
L' utilizzo e' pero' individuale e  non ho mai sentito la necessita'
delle transazioni ed anche della integrita' referenziale, foreign keys
non li ho mai usati e neppure ne conosco esattamente l' impiego.
Per questo stavo anch' io pensando a Mysql ma mi bloccano due problemi 
dei quali, se sarai disponibile, te ne parlero' in altro thread. 
Altri database quali Adabas e Interbase4 come sono rapportati alle mie 
esigenze?
Non li conosco affatto.
Grazie per l' aiuto.
Daniele

Hai usato gli indici?
Non li ho usati perche goa' in Access mi rallentavano notevolmente la 
immissione dei dati (ne muovo quotidianamente sull' ordine dei 10.000 
in tabelle a validita' giornaliera).
Temo che analogo rallentamento all' immissione si verificherebbe con
qualsiasi database.
Daniele

 di records e le analisi sono sotto forma di grafici (OLE).
Se fai spesso delle creazioni, in PostgreSQL ti conviene disabilitare il
flush per ogni transazione (abilitare il flag -F).
A risentirci
\  Davide G. Borin
\\ !!Scudo anti-spam attivo!! Togliere le x e "eliminami" dall'indirizzo
\\\_____________________________________________________________________

non li ho mai usati e neppure ne conosco esattamente l' impiego.
Allora forse MySQL e' la scelta migliore.


qualsiasi database.
Pero' MySQL ha l'INSERT DELAYED :-)


Tra la documentazione ho sentito parlare di questo file "pg_geqo" che
dovrebbe contenere
delel impostazioni relative al demone ... parlano di performance ...
nessuno ha mai dato un' occhiata alla cosa ?
-- 
*  Sgt. Pepper's Lonly Hearts Club Band * We Hope You Have Enjoy The
Show  *
| Il prezzo dei CD musicali è ingiusto ! Ingrassano le
multinazionali,     |
| svuotano i nostri portafolgi e uccidono la diffusione della musica.
Non  |
| comprate CD a prezzo pieno. Comprate offerte , CD usati e scaricate
MP3. |

qualsiasi database.
Ma, io credo che se devi fare ricerche su 500.000 records senza indici
troverai lento probabilmente anche Oracle ... ;-)
A meno che tu non possa *ordinarli* fisicamente i tuoi archivi su
disco, e le tue ricerche coincidano in larga parte con la scansione
sequenziale degli archivi ...
In ogni caso fossi in te proverei a testare il costo in termini di
prestazioni per l'inserzione dei tuoi 10.000 records in archivi
indicizzati e/o se puoi trovare della politiche di inserzione che non
vadano ad impattare meno con l'uso del sistema (ad esempio in orari
non di punta). 
Credo che i vantaggi in termini di tempo per le ricerche, potrebbero
piu' che valere quello che perdi dal lato dell'inserzione: d'altra
parte non servono proprio a questo gli indici? :-)
ciao Michele

qualsiasi database.
Dato che sto scaricando un po' di roba, ho dato un'occhiata al
manuale, che riporta dei suggerimenti proprio per il problema che tu
indichi, quello di una grossa mole di inserimenti:
One may need to do a large number of table insertions when first
populating a database. Here are some tips and techniques for making
that as efficient as possible. 
Disable Auto-commit
Turn off auto-commit and just do one commit at the end. Otherwise
Postgres is doing a lot of work for each record added. In general when
you are doing bulk inserts, you want to turn off some of the database
features to gain speed. 
Use COPY FROM
Use COPY FROM STDIN to load all the records in one command, instead of
a series of INSERT commands. This reduces parsing, planning, etc
overhead a great deal. If you do this then it's not necessary to fool
around with autocommit. 
Remove Indices
If you are loading a freshly created table, the fastest way is to
create the table, bulk-load with COPY, then create any indexes needed
for the table. Creating an index on pre-existing data is quicker than
updating it incrementally as each record is loaded. 
If you are augmenting an existing table, you can DROP INDEX, load the
table, then recreate the index. Of course, the database performance
for other users may be adversely affected during the time that the
index is missing.
Credo che quest'ultimo metodo possa essere proprio quello che potrebbe
andarti bene ... dato che ridurrebbe sia il tempo per il carico dei
dati (non c'e' l'indice a causa del drop index), sia quello per le
ricerche (una volta finito con le inserzioni puoi ricrearti
l'indice;-)
ciao Michele

flush per ogni transazione (abilitare il flag -F).
Bene, questo non lo sapevo.
Grazie per i consigli.
Daniele
dval...@tiscalinet.it

Allora forse MySQL e' la scelta migliore.
Da quanto sto vedendo direi di si anche se mi rimangono alcuni 
interrogativi:
Adabas e Interbase4?
Qualcuno li conosce e li ha provati?
Come sono le interfacce grafiche di Mysql?
(Pgaccess di PostgreSQL mi e' parsa limitata ed inoltre non mi ha 
permesso l' import dei dati  da file, temo che sia un suo bug).
Daniele
dval...@tiscalinet.it

Disable Auto-commit
ottimo consiglio
con auto-commit  insert circa 1000 al minuto
con disable a-c  insert circa 25000 al minuto
bye
-- 
     #@@@ missinglink on slackware 7.1 ###
     ####       member of telug        #@@
 

bye
In effetti confrontare le prestazioni di PostgreSql con quelle di
altri sistemi, come ad esempio MySql, mi sembra davvero inappropriato:
e' chiaro che MySql puo' fornire prestazioni talvolta eccellenti, dato
che non deve garantire tutte quelle caratteristiche che fanno di
PostgreSql un vero database di razza. In MySql (e per quel che mi
risulta anche in Access) infatti, non occorre disabilitare
l'autocommit per aumentare le prestazioni, dato che quella
caratteristica, cosi' come tante altre, non e' nemmeno presente!
Sta poi al programmatore sfruttare le potenzialita' che fanno al caso
suo, e/o il motore di database che piu' gli convengono ;-)
ciao Michele

record restituiti 491.085
Mah. Un'altra cosa che mi viene in mente e' che ben difficilmente ti
troverai a dover fare una SELECT cosi' grossa, e che forse c'e' modo
di diminuire il numero di records ritornati.


record restituiti 491.085
Perche' strano? E' chiaro che se il risultato della ricerca contiene
tutti i record dell'archivio, gli indici non servono a una mazza, dato
che deve passarseli comunque a uno a uno (e quindi e' obbligato
comunque ad accedere al disco). A quel punto le prestazioni dipendono
da come sono memorizzate fisicamente le schede, e dal fatto che siano
o meno *fisicamente* ordinate sul disco. 
In Postgres quest'ultima opzione si ottiene con i Cluster:
"CLUSTER instructs Postgres to cluster the class specified by table
approximately based on the index specified by indexname. The index
must already have been defined on classname. 
...
In cases where you are accessing single rows randomly within a table,
the actual order of the data in the heap table is unimportant.
However, if you tend to access some data more than others, and there
is an index that groups them together, you will benefit from using
CLUSTER. 
Another place where CLUSTER is helpful is in cases where you use an
index to pull out several rows from a table. If you are requesting a
range of indexed values from a table, or a single indexed value that
has multiple rows that match, CLUSTER will help because once the index
identifies the heap page for the first row that matches, all other
rows that match are probably already on the same heap page, saving
disk accesses and speeding up the query.
..."
Gli indici infatti servono proprio per limitare il numero di accessi
del database al disco, quando ti serve una piccola *porzione* di una
grande quantita' di dati. Prova a mettere una condizione un po'
restrittiva, che limiti il numero di record restituiti, e poi prova a
fare i confronti ;-)
Detto questo, non ho capito cosa ti serve una select che ti
restituisce 491.085 records... mi auguro che tu non debba poi
controllarli a uno a uno ... :-)
Tieni presente che i database devono servire a manipolare
l'informazione, in modo che tu possa ricavare conoscenza: ma tra la
quantita' di informazione disponibile, e la conoscenza che riesci a
ricavare, c'e' spesso un rapporto *inversamente* proporzionale ... ;-)
ciao Michele


Si, e' vero e penso che solo i grafici riescano a sintetizzare grandi 
quantita' di dati.
Comunque ti ringrazio per le precise e pazienti indicazioni che mi hai
dato nei vari messaggi: capisco di avere ancora parecchio da studiare
sull' ambiente Linux ed i  suoi databases.
Purtroppo non sono programmatore: di professione sono agricoltore ed
amministratore, da non molto uso linux, sono un po' anziano ed ho
poco tempo libero: ho una strada in salita piuttosto ripida.
Le SELECT in oggetto sono solo per prova ma analoghe SELECT su tutto il 
database mi costruiscono giornalmente le tabelle di performances di
fondi ed azioni rispetto a date di riferimento  (fine anno, fine
trimestre, ecc), una roba di questo genere (la sintassi e' di un batch 
di MySQL):
connect dan
#set SQL_BIG_TABLES=1;
DROP TABLE fondperf9912;
CREATE TABLE fondperf9912
(
	nome	  varchar(25) NOT NULL,
	data	  date NOT NULL,
	perf9912  float(4)
);
INSERT INTO fondperf9912
SELECT fondi.nome,fondi.data,((fondi.valore/fondi9912.valore)-1)*100
AS perf9912
FROM fondi,fondi9912
WHERE fondi.nome = fondi9912.nome;
#LIMIT 100000;
 
Ponendo cosi' in tabelle tutte le performances di tutti i titoli
rispetto alle  principali date di riferimento diviene rapido costruire i
grafici di andamento medio di settore, di SIM, del singolo titolo,
confronti, valutazione di strategie e cosi' via.
E' un lavoro piuttosto ampio sviluppato in Access2 e comprende lo 
scarico automatico quotidiano dei dati da scheda televideo.
Purtroppo il passaggio da microsoft a linux e' piuttosto doloroso, 
specie a causa della scheda televideo che non riesco a far  funzionare in
linux (utilizza il chip SAA5249 della Philips).
Ma questo e' estraneo a postgres ed a database: se riesco ne riparlero'
in altro  thread.
Daniele
dval...@tiscalinet.it


E non me ne ero accorto.
Lo studiero'.
Grazie.
Daniele
dval...@tiscalinet.it

in altro  thread.
In realta', qui linux centra poco, almeno se escludiamo il fatto che
un magnifico database come PostgreSql e' stato sviluppato nella stessa
ottica di Linux, ossia come software libero: linux infatti, purtroppo
lo conosco ancora poco anch'io ... :-)
In bocca al lupo,
ciao Michele

In realta', qui linux centra poco, 
Ops, ho letto male e scambiato lucciole per lanterne: non stavi
parlando di database ... :-(
ciao Michele

 permesso l' import dei dati  da file, temo che sia un suo bug).
A me funziona ... con una 6.5.2 ... cmq ho trovato piů comodo passare 
per ODBC visto che la mia fonte era su M$Access ... lentamente ma
funziona 
poi ho ricostriuto e sistemato altre cosine facendo il dump con pg_dump
del
DB , modificato la struttura sul file e poi infine import con psql .
-- 
*  Sgt. Pepper's Lonly Hearts Club Band * We Hope You Have Enjoy The
Show  *
| Il prezzo dei CD musicali č ingiusto ! Ingrassano le


In bocca al lupo,
Grazie Michele, saro' lieto di incontrarti ancora.
-- 
           Daniele
 
dval...@tiscalinet.it