Linguaggi procedurali PostgreSQL overhead (plpython / plsql / pllua ...)

Sto cercando di trovare informazioni sulle funzioni definite dall'utente di PostgreSQL nelle prestazioni dei linguaggi procedurali per attività in tempo reale.

1. Come si confrontano con le funzioni integrate?
2. C'è qualche differenza (in termini generali) su come Postgres chiama / gestisce le funzioni plpython vs plpgsql vs pllua (sono interessato al lato integrazione / contesto / trasferimento dati di Postgres, non alla VM stessa)?
3. Il contesto è un grande sovraccarico? Posso usarlo per la mappatura dei dati in tempo reale (diciamo 1000 query / s))
4. C'è qualche vantaggio nello scrivere funzioni definite dall'utente in plpgsql e poi in altre lingue / linguaggio? Sulla documentazione elencano i vantaggi, ma penso che si applichino a tutti i linguaggi procedurali postgresql.

Risultati correlati:

• Una velocità di linguaggi PL per uso atipico
• Funzione PostgreSQL Prestazioni del linguaggio: C vs PL / PGSQL

1. Gli UDF nei linguaggi interpretati sono praticamente sempre più lenti degli UDF scritti in C o funzioni incorporate, essendo tutte le altre cose uguali.

2. Ogni associazione linguistica ha un codice diverso per connettere PostgreSQL alla lingua, con diversi gradi di ottimizzazione, diversi modi di trasmettere alcuni tipi di dati, ecc. Quindi esiste sicuramente una variazione. Non dovrebbe essere enorme a meno che non si stia passando un tipo di dati che ottiene una gestione molto diversa da una lingua rispetto a un'altra, ad esempio una passa hstorecome una stringa e un'altra la converte in una dict.

3. Non è chiaro quale sia il "contesto". Puoi usarlo per la "mappatura dei dati in tempo reale" ... beh, dipende da cosa fa la funzione e se è abbastanza veloce sul server su cui è in esecuzione, per i client a cui si rivolge e per le tue esigenze. Quanto dura un pezzo di spago? Prova delle prestazioni.

4. PL / PgSQL è più semplice da scrivere e offre un accesso più rapido a SQL. È generalmente meglio quando è necessario avvolgere un po 'di logica attorno a un sacco di SQL. È molto lento per operazioni matematiche e algoritmi complessi, quindi il codice puramente computazionale in PL / PgSQL dovrebbe essere evitato, ove possibile, a favore di C, o di un linguaggio procedurale più veloce.

Le accelerazioni nella reimplementazione del codice PL / PgSQL in C possono variare da neglible a oltre 1000 volte. Tutto dipende da cosa sta effettivamente facendo il codice.

(Questo tipo di domande multiple non è adatto allo Stack Stack poiché è più difficile avere una risposta definitiva)

questo è piuttosto difficile da dire. dipende davvero da cosa stai facendo. per esempio: PL / pgSQL è meraviglioso se hai grandi istruzioni SQL in esso - diventa davvero pazzo se hai tutti i tipi di branching, gestione delle sottostringhe e tutto il resto.

devi davvero testare caso per caso.

Il contesto è un grande sovraccarico? Posso usarlo per la mappatura dei dati in tempo reale (diciamo 1000 query / s))

Le prestazioni dipendono dall'hardware e dalla complessità delle funzioni. Ho creato un'appliance che funzionava su un piccolo server a 12 core e una scheda FusionIO (costi totali 10000 euro) e ho effettuato circa 2500 transazioni al secondo con 20 utenti simultanei. Ogni transazione chiama 29 procedure memorizzate per l'elaborazione dei dati e la restituzione di alcune informazioni utili al cliente. Alcune funzioni eseguono solo una query, altre un paio di query. In totale, esegue circa 200000 istruzioni INSERT, SELECT e UPDATE al secondo.

Tutto questo è scritto in PL / SQL, PL / pgSQL e PL / PerlU. E sono abbastanza sicuro che il sistema possa funzionare ancora più velocemente quando (alcune) funzioni vengono riscritte in C.

In questo dispositivo, la maggior parte delle prestazioni deriva dalla scheda SSD. Su un singolo disco rotante, non potremmo mai ottenere questa prestazione. Anche le unità SSD economiche non funzionano, funziona per un'ora (a causa della memorizzazione nella cache della scheda raid) e quindi il gioco è finito. La scheda FusionIO è costosa, ma è un ottimo investimento quando si è legati all'IO.