Re: Caching driver on pgFoundry?

Seen this too. However I did spend a significant amount of time
tuning these applications since they have to deliver a certain
throughput. Statement caching is definitely helpful in those cases.
For the ones you describe could it be that the dbase layer is just
storage and not part of the (critical) performance path?
If the database related work is critical in performance/throughput
than caching is a welcome technology.
I found this matters for the lower level apps to establish call
setups, check balance on pre paid, and these basic thing were every
tick translates into a tiny bit of money. Unfortunately there are an
awful lot of these tiny little bits. This is what makes it so
interesting from a performance tuning perspective that is.
And yes some of the telco ISVs use Times Ten to do it all in memory.
In that case everything is cached. Mmmm could be a nice extension for
PG...

--Paul

On 6-sep-2007, at 11:14, Oliver Jowett wrote:

> Paul van den Bogaard wrote:
>
>> Finally it is not just appsservers out there. Lots if J2SE
>> application exist in at least the Telco segment. Would love to see
>> these guys to adopt a free database instead of Oracle that is all
>> over that place.
>
> Going off at a bit of a tangent here.. OpenCloud does telco
> infrastructure software and we package postgresql with our product
> to do persistence of long-lived state (deployed services, cluster
> configuration, customer provisioning data etc). The statement
> caching stuff is not really an issue either way for what we do,
> since we already intelligently reuse statements in our persistance
> layer.
>
> One thing we've found is that our customers don't really care about
> database setup for this sort of use, they want it to "just work".
> In fact we package Derby instead of PostgreSQL with our development
> versions just so there's one less thing for the developer to set
> up. So even if we cared about statement caching it wouldn't really
> matter if it was together with the driver or a separate package as
> we'd still end up doing all the packaging together with the
> application and testing of the combined product.
>
> While what we do is essentially an appserver (JAIN SLEE) I suspect
> the same applies to standalone java telco apps, you're going to be
> doing DB integration as part of your app not as something that gets
> plugged in afterwards, so I'm not sure how relevant having it in
> the standard driver is.
>
> -O

------------------------------------------------------------------------
---------------------
Paul van den Bogaard
Paul(dot)vandenBogaard(at)sun(dot)com
CIE -- Collaboration and ISV Engineering, Opensource Engineering group

Sun Microsystems, Inc phone: +31
334 515 918
Saturnus 1
extentsion: x (70)15918
3824 ME Amersfoort mobile: +31
651 913 354
The Netherlands
fax: +31 334 515 001