Sto cercando di migliorare le prestazioni di una stored procedure plpgsql di lunga durata, ma non ho idea di quali strumenti di profiling siano disponibili. Qualcuno può offrire suggerimenti su come definire una procedura simile?Come profilo procedure plpgsql
Sollevare alcuni notices dalla procedura incluso lo clock_timestamp() per vedere dove trascorre il tempo il database. E rendere le procedure il più semplici possibile.
Puoi mostrarci un esempio?
Per iniziare, è possibile attivare logging of all statements nel file di registro Postgres. Il log conterrà il runtime per ogni istruzione. In questo modo puoi identificare le query più lente e cercare di ottimizzarle.
Ma leggendo il tuo commento sul post di Frank, immagino che il loop sia il tuo problema. Cerca di sbarazzarti del ciclo e fai tutto in una singola query. Una dichiarazione che legge un sacco di righe è in genere più efficiente di molte affermazioni che leggono solo poche righe.
Provare a utilizzare l'estensione pg_stat_statements (http://www.postgresql.org/docs/9.2/static/pgstatstatements.html). Può visualizzare il numero di chiamata e il tempo di chiamata totale per tutte le istruzioni (incluse le istruzioni secondarie all'interno delle procedure di plpgsql).
Siamo attualmente alla ricerca di una risposta migliore a questa domanda, e sono imbattuti in questo strumento: http://www.openscg.com/2015/02/postgresql-plpgsql-profiler/ Ospitato presso: https://bitbucket.org/openscg/plprofiler
Essa sostiene di darti quello che stai cercando, compreso il tempo totale speso su ogni riga della funzione. Non l'abbiamo ancora approfondito, ma sulla base delle affermazioni dell'autore, siamo ottimisti.
Speravo in un metodo che non richiedesse modifiche alla procedura, ma probabilmente sarebbe meglio di niente. http://www.depesz.com/index.php/2010/03/18/profiling-stored-proceduresfunctions/ documenta una procedura simile, ma sembra eccessivamente complicato ottenere dati utilizzabili. La procedura è una serie di cicli nidificati utilizzati per creare documenti per una query del gestore di importazione dati Solr, se ciò è di aiuto (probabilmente no). – Aneurysm9
Non è un ottimo modo per farlo, ma è l'unico modo. Questo è anche il motivo per cui è importante mantenere le cose corte e semplici: le procedure brevi sono molto più facili da eseguire il debug e il profilo, proprio come gli altri codici. –
Sfortunatamente, la procedura è tanto semplice quanto può ottenere. Segue una serie di relazioni 1: n selezionando alcuni dati, iterando su n, selezionando più dati, iterando su relazioni nidificate 1: n, quindi RETURN NEXT dal ciclo interno una volta che una riga completa è pronta. Tutto più complesso di SELECT o FOR è già stato inserito in altre procedure. – Aneurysm9