Re: BLOB performance test FYI
От | Barry Lind |
---|---|
Тема | Re: BLOB performance test FYI |
Дата | |
Msg-id | 3CBEFC09.1000203@xythos.com обсуждение исходный текст |
Ответ на | Re: BLOB performance test FYI ("Joe Shevland" <jshevland@j-elite.com>) |
Список | pgsql-jdbc |
Joe, I think at least initially things can be a lot simpler: Joe Shevland wrote: > > * Using tools.jar to parse and compile the function source code I would suggest that we just follow the lead of C functions. The database doesn't compile your C source when you register a C function, you just tell the database where the precompiled code is and what the entry point is. To start with, I think the java version should do the same. Tell the server the statuc class.method to run, but leave the compiling and loading the classes to the user. > * One JVM per PostgreSQL server (configurable via postgresql.conf) Yes. > * One classloader per database to keep things clean and separate Sure. > * JSP-like compilation - functions compiled when there is a change in the code, or first created. Otherwise remains memoryresident as a class instance, and/or is created on server startup. Overkill (at least initially) see my comments above. > * Communication would be via JNI (Java<->C): the JVM would be assumed to be resident on the same server... unless we'dwant to look at load balancing, again I keep thinking of the boundaries of what the db should do. Should reuse the FE/BE protocol, and then much of the work is done in the existing jdbc driver code > * Mapping between Java and PG types handled by a central thing Already handled by the existing FE/BE code in both jdbc and the server. > > Wading further and further into deep water here I think, > > Cheers, > Joe > thanks, --Barry
В списке pgsql-jdbc по дате отправления: