[Pljava-dev] Re:

info at wyse-systems.ltd.uk wrote:

>If you are trying to convince me that calling a method 1000s of times
>passing two parameters at each call is more efficient (both memory- and
>performance- wise) than having a single call building the entire result set
>which is then processed internally row by row, if desired, by PostgreSQL -
>well, you can't.
>
>
What do you think the backend needs to do when the ResultSet is
"processed internally row by row"? That's 1000's of calls too you know.
You won't gain a single bit of performance by first building the set
(that in itself would amount to 1000's of calls) and then pass it to
PostgreSQL who now must do 1000's of calls just to retrieve the data all
over again.

And memory-wise? Well, my solution never build a set in memory. Yours
do. So how you can come to the conclusion that your solution is more
memory efficient is beyond me.

So George, please think this through, from the time when you start
building your set and to the time the function returns it. I asked you a
number of questions in my last two mails. In order to answer those
questions, you need to dig a bit deeper. In essence, you need to
understand the concept of data streaming. My intention by asking those
questions was to give you hints on difficulties in the domain we are
discussing and increase your understanding. Right now it seems you're
sticking your head in the sand and perform lots of ungrounded handwaving
without listening to (or care about) what I'm trying to explain.

>I will take the necessary steps to bring alterations to the code as I see
>fit so to make sure it suits our needs and requirements (at the end of the
>day we a running a business, not a charity).
>
>
You may be pleased to know that a solution that caters for your special
need, i.e. returning a ResultSet, has been implemented already. It's in
CVS head and it's working fine. If you'd care to try it out, I'd be
happy to address any issues that you would find with it. A simple but
efficient ObjectPool is in place too. If your business benefits from
this, perhaps you should make a donation
(just kidding, but perhaps a joke can bring things into perspective?).

If you come up with a more efficient solution and want to contribute it,
it will be accepted.

>For me, personnally, this is the end of the matter and I consider the
>entire issue closed.
>
>
Well, let's close it here then. For me personally, who wrote the code
that you are criticising, it's essential to try to convey to you what
the underlying mechanisms actually does. I advice you to study what
needs to be done a bit further. I'd be happy to bring this discussion up
again when you have more concrete and viable suggestions on how to
improve PLJava.

I really do acknowledge that it was your ideas that brought the new
capabilities (returning a ResutlSet and using an ObjectPool) to PLJava,
and I want to thank you for it.

Regards,
Thomas Hallgren