2014-09-15 19:34 GMT+02:00 cowwoc <cowwoc@xxxxxxxxxxxxxxxx>:
On 15/09/2014 7:03 AM, Chris Travers wrote:
I have a few questions on this, the answers of which may help answer your question:
1. How well does having a server-side JVM work, resource-wise, when you have a forked process model like PostgreSQL? Does having the additional JVM's pose performance and competition for resources that lighter languages would not?
I don't think this is really a concern when connection pooling is used (otherwise you end up creating a new JVM per connection which is indeed problematic).
2. What is your specific use case for a trigger in Java?
The main drivers are:
- Not having to learn yet another language. I find the expressiveness and readability of the other scripting languages very clunky compared to Java.
PLpgSQL is different, it is based on Ada language
- Ease of porting triggers across databases. The only thing that really changes across databases is how triggers interact with input/output parameters. The main body remains the same (thanks to JDBC). This is quasi portability in the sense that the underlying SQL is itself quasi portable, but I find it a much more compelling approach than having to rewrite the triggers for each database type.
any time plpgsql will be faster then Java probably due a type compatibility with Postgres and execution as inprocess
There is a few task, that can be done in database, that will be faster in PL/Java than PL/pgSQL
Regards
Pavel
Pavel
Gili
