linux user group brescia

> quindi una query che dia come risultato una tuple sola fuori dal server, e
> solo quella.
> cercavo una variabile, cioe' un dato temporaneo da dare al server, per
> metterlo poi
> dentro un WHERE di una query, la quale mi ritorna vuota se il dato
> temporaneo manca.

Secondo me e' errato pensare di dare al server un parametro; per quanto mi risulta il tutto dovrebbe procedere secondo questo schema

1) il client assembla una query fatta e finita, in particolare sostituisce il valore attuale a _tutti_ i parametri formali e ottiene una stringa ASCII contenente uno statement SQL valido

2) il client invia lo statement al server

3) il server elabora lo statement, costruisce il result set e lo rispedisce indietro

4) il client legge il result set.

Tutte le operazioni di selezione, proiezione e join vengono svolte sul server (come e' giusto che sia). Quello che transita in rete e' 

*) la stringa contenete la query sql
*) il result set _finale_ cioe' solo i dati che compongono il tuo risultato (e non e' detto che siano _tutti_ i record, vedi cursori). 


> sto leggendo di cursori, ma o non e' quel che cerco o non ho capito bene
> l'uso che ne posso fare.

Un cursore e' un modo per leggere il result set un record per volta, in maniera sequenziale o random. Da come ho capito io il tuo result set dovrebbe essere composto di una unica tupla, quindi aprire un cursore e' inutile; tuttavia in alcuni linguaggi (es java) i result set si possono interrogare solo usando un cursore. Se il linguaggio che usi ti da la possibilita' di ottenere direttamente l'intero result set con uno statement unico, fregatene dei cursori.

 
> access non e' un client, lo sto usando come tale, e non so esattamente come
> funziona.
> in access in collego le tabelle remote, e la query la faccio su quelle.
> sia la tabella che la query sono su access, e non vorrei che, appunto,
> quando esegue una query,
> la esegua in locale, collegandosi _tutte le volte_ alle tabelle collegate
> come se fossero sulla macchina.
leggero che faccia _solo_ da client e prova a mandare a mano la query (quella costruita al punto 1); in questo modo puoi eseguire una  misura _reale_ del tempo impiegato e della dimensione dei dati scambiati. Puo' essere che access ci metta del suo e che quindi faccia effettivamente le operazioni di selezione e proiezione in locale (personalmente mi sembra un comportamento da matti, ma ....) Morale, ripeto, togliti da piedi _qualunque_ sw che manipoli (anche solo potenzialmente) il result set dopo che l'ha ricevuto dal server. E' chiaro che se impieghi comunque 10 minuti per ricevere i risultati anche da un client leggero (ad esempio il client da command line, sia benedetto!) il problema sta nella formulazione della query o nella definizione della base dati; tanto per spararne una, io non ricordo come fosse la tua query originale ne' che dimensione avesse la tua base dati, ma e' ovvio che se metti una clausola del tipo WHERE campoX='pippo' e la tabella ha migliaia di record allora e' buona cosa mettere un indice su campoX.


Altra cosa, io non conosco a sufficienza postgres, ma su molti db c'e' la possibilita' di abilitare numerosi tracciamenti lato server, ad esempio e' possibile tenere sotto controllo l'esecuzione delle query e conoscere plan e tempo di esecuzione, indici usati e cardinalita' del risultato. 


ciao
gv