Re: pl/Ruby, deprecating plPython and Core

Dave,
Some responses inline. As a reaction to what Josh just wrote - "Keep in
mind that for us non-Java geeks most of your argument is pure ancient
Greek" - I'll try to talk in generic terms from now on and not mention
Java since the difference between our solutions have nothing whatsoever
to do with Java. Java is what we have in common :-)

I'm all in favor of writing a good descriptive chapter that explains the
differences between the solutions.

Dave Cramer wrote:

>> 1. Speed. One major reason for moving code from the middle tier down
>> to the database is that you want to execute the code close to the
>> actual persistence mechanisms in order to minimize network traffic
>> and maximize throughput.
>
> I think until there are actual benchmarks, there are too many
> variables here to suggest one is faster than the other. The overhead
> of having multiple java vm's is not easily estimated. Even with a
> connection pool, consider the memory footprint of even 10 java VM's

I think it would be a very good idea to jointly create a test bench
where we can measure performance. Not only could we make just
comparisons between our solutions, we could also use it to improve on
them. The results could also be included in the documentation section
that Josh requests and serve as facts for decision making.

The reason I brougth the speed issue up is that I felt that you
mentioned PL/Java's two weakest points (memory consumption and startup
time) but failed to mention the weakest point of PL-J (slow
inter-process calls).

A side-note:
The footprint of 10 VM's doesn't scare me that much. A modern VM that
doesn't run an app-server and no GUI doesn't consume that much (they
sure used to though). On my Windows-XP box, one VM typically consumes
about 20-40Mb virtual memory and 6-13Mb real memory. I currently have 50
VM's running simultaniously without problems.

>> 3. Transaction visiblity. A function that in turn issues new SQL
>> calls must do that wihtin the scope of the caller transaction. A
>> remote process must hence call back into it's caller. PL/Java has
>> its own JDBC driver that interacts directly with SPI.
>
> PL-J maintains transaction visibility, it has it's own JDBC driver as
> well. The protocol between the language handler and the java portion
> is based upon the FE/BE protocol which made it easy to use pg's JDBC
> driver with some modification.

Ok, Bad heading. My point was that for each call you make from the
backend to the VM, the VM must make a call back to the caller, receive
the results, and then propagate those results back to the caller that
actually had them in the first place. That's a lot of unnecessary
network traffic. The relevance of this should of course also be tested
in the test bench.

> PL-J requires one other module, which the build environment will
> fetch automatically to compile.

PL-J Requires a specific build environment. Thats one dependency. In
addition there are 6 dependencies listed in its project descriptor.

The problems that arise when you depend heavily on other modules are not
just related to how they are obtained. You need to keep track of bugs
that concern you, their fixes and release versions. You want to know
about new features that you might want to use (while still maintaining
backward compatibility of course), and you must watch out for
inter-component dependencies and version conflicts that might arise
every time you bump a version of something. There might be licensing
issues, etc. When PL/Java was designed I made a serious effort to avoid
all that. Hence my concern.

Regards,
Thomas Hallgren