JDBC team,

I may have missed some stuff over the holiday weekend, but why is the new
caching wrapper on pgfoundry instead of on jdbc.postgresql.org?

--
Josh Berkus
PostgreSQL @ Sun
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Josh Berkus wrote:
> I may have missed some stuff over the holiday weekend, but why is the new
> caching wrapper on pgfoundry instead of on jdbc.postgresql.org?

See the discussion here:
http://archives.postgresql.org/pgsql...7/msg00137.php
continuing in August here:
http://archives.postgresql.org/pgsql...8/msg00006.php

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Heikki,

> See the discussion here:
> http://archives.postgresql.org/pgsql...7/msg00137.php
> continuing in August here:
> http://archives.postgresql.org/pgsql...8/msg00006.php

I understand why it's a wrapper. I don't understand why the wrapper isn't at
jdbc.postgresql.org. Putting it on pgfoundry, completely separate from all
the JDBC drivers, is pretty much a guarentee that nobody will ever download
it.

Or is it moving to jdbc.postgresql.org once it's tested?

Just so everyone is clear on why this is important & urgent ... we published a
benchmark[1] using the caching driver, which is the only published benchmark
PostgreSQL has. This benchmark has generated a huge amount of interest in
PostgreSQL as an alternative to Oracle[2], and is very important to driving
the adoption of PostgreSQL *especially* amoung J2EE developers. So it would
be nice to see the caching wrapper represented as "official" unless there's
something technically wrong with it.

[1]http://www.spec.org/jAppServer2004/results/res2007q3/jAppServer2004-20070703-00073.html
[2]http://www.informationweek.com/showArticle.jhtml?articleID=201001901

--
Josh Berkus
PostgreSQL @ Sun
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Josh Berkus wrote:
> I understand why it's a wrapper. I don't understand why the wrapper isn't at
> jdbc.postgresql.org. Putting it on pgfoundry, completely separate from all
> the JDBC drivers, is pretty much a guarentee that nobody will ever download
> it.

I don't have a problem with linking from jdbc.postgresql.org to the
wrapper. And other pooling and caching implementations as well while
you're at it.

> Just so everyone is clear on why this is important & urgent ... we published a
> benchmark[1] using the caching driver, which is the only published benchmark
> PostgreSQL has. This benchmark has generated a huge amount of interest in
> PostgreSQL as an alternative to Oracle[2], and is very important to driving
> the adoption of PostgreSQL *especially* amoung J2EE developers. So it would
> be nice to see the caching wrapper represented as "official" unless there's
> something technically wrong with it.

Can't you use DBCP or some other open source statement cache
implementation that's in a more mature state? Or actually, why don't you
have a statement cache in Sun Application Server like the competitors? ;-)

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Heikki,

> I don't have a problem with linking from jdbc.postgresql.org to the
> wrapper. And other pooling and caching implementations as well while
> you're at it.

Only one I can think of is Sequoia.

> Can't you use DBCP or some other open source statement cache
> implementation that's in a more mature state?

Unfortunately, no. The benchmark is already out.

> Or actually, why don't you
> have a statement cache in Sun Application Server like the competitors? ;-)

Don't even get me started.

--
Josh Berkus
PostgreSQL @ Sun
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

On 5-Sep-07, at 12:21 PM, Heikki Linnakangas wrote:

> Josh Berkus wrote:
>> I understand why it's a wrapper. I don't understand why the
>> wrapper isn't at
>> jdbc.postgresql.org. Putting it on pgfoundry, completely separate
>> from all
>> the JDBC drivers, is pretty much a guarentee that nobody will ever
>> download
>> it.
>
The drivers will end up there eventually anyway.
And we can link it to the jdbc home page.

Dave
> I don't have a problem with linking from jdbc.postgresql.org to the
> wrapper. And other pooling and caching implementations as well while
> you're at it.
>
>> Just so everyone is clear on why this is important & urgent ... we
>> published a
>> benchmark[1] using the caching driver, which is the only published
>> benchmark
>> PostgreSQL has. This benchmark has generated a huge amount of
>> interest in
>> PostgreSQL as an alternative to Oracle[2], and is very important
>> to driving
>> the adoption of PostgreSQL *especially* amoung J2EE developers.
>> So it would
>> be nice to see the caching wrapper represented as "official"
>> unless there's
>> something technically wrong with it.
>
> Can't you use DBCP or some other open source statement cache
> implementation that's in a more mature state? Or actually, why
> don't you
> have a statement cache in Sun Application Server like the
> competitors? ;-)
>
> --
> Heikki Linnakangas
> EnterpriseDB http://www.enterprisedb.com
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

On Wed, 5 Sep 2007, Josh Berkus wrote:

>> Can't you use DBCP or some other open source statement cache
>> implementation that's in a more mature state?
>
> Unfortunately, no. The benchmark is already out.
>

But that benchmark was run with a different caching implementation than
the wrapper version, so I'm not sure how that's relevant. When Sun chose
to use unpublished and unreviewed code for the benchmark they got
themselves in a little bind and I'm not sure it's our job to bail them out
by publishing and advertising code that we're not confident in. Heikki,
Oliver, and myself did not believe the code used by Sun in the benchmark
was correct in the general case so it was rejected for inclusion in the
core driver. Dave/Lazlo have since started a new implemention on
pgfoundry, but that was never discussed with the JDBC list or submitted
for inclusion.

To satisfy the benchmark requirements, Sun should publish the code/driver
actually used in the benchmark somewhere on Sun's website and, if honest,
should recommend that people don't use it. From there we should try to
gather some consensus on whether PG needs its own statement cache
implementation and then rerun the benchmarks with it or some other
implementation.

Kris Jurka

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

On 5-Sep-07, at 1:27 PM, Kris Jurka wrote:

>
>
> On Wed, 5 Sep 2007, Josh Berkus wrote:
>
>>> Can't you use DBCP or some other open source statement cache
>>> implementation that's in a more mature state?
>>
>> Unfortunately, no. The benchmark is already out.
>>
>
> But that benchmark was run with a different caching implementation
> than the wrapper version, so I'm not sure how that's relevant.
> When Sun chose to use unpublished and unreviewed code for the
> benchmark they got themselves in a little bind and I'm not sure
> it's our job to bail them out by publishing and advertising code
> that we're not confident in. Heikki, Oliver, and myself did not
> believe the code used by Sun in the benchmark was correct in the
> general case so it was rejected for inclusion in the core driver.

So as I understand it the objection to the caching implementation is
that statement caching belongs in the app server ?

If this is the case then I would argue that having caching in the
appserver is a great idea for everyone using an appserver it does not
help the rest of the world that doesn't use an app server.

Is there a technical argument here ?

Dave

> Dave/Lazlo have since started a new implemention on pgfoundry, but
> that was never discussed with the JDBC list or submitted for
> inclusion.
>
> To satisfy the benchmark requirements, Sun should publish the code/
> driver actually used in the benchmark somewhere on Sun's website
> and, if honest, should recommend that people don't use it. From
> there we should try to gather some consensus on whether PG needs
> its own statement cache implementation and then rerun the
> benchmarks with it or some other implementation.
>
> Kris Jurka
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

On Wed, 5 Sep 2007, Dave Cramer wrote:

>
> On 5-Sep-07, at 1:27 PM, Kris Jurka wrote:
>
>> But that benchmark was run with a different caching implementation than the
>> wrapper version, so I'm not sure how that's relevant. When Sun chose to
>> use unpublished and unreviewed code for the benchmark they got themselves
>> in a little bind and I'm not sure it's our job to bail them out by
>> publishing and advertising code that we're not confident in. Heikki,
>> Oliver, and myself did not believe the code used by Sun in the benchmark
>> was correct in the general case so it was rejected for inclusion in the
>> core driver.
>
> So as I understand it the objection to the caching implementation is that
> statement caching belongs in the app server ?

No, the objection above is that the code you originally submitted was not
good enough to be included in the driver regardless of whether it should
be in the driver or app server. If we aren't using the code that you
originally submitted then the argument that we need to publish something
for benchmark compliance is silly because the requirement is you publish
the code/driver used, not a somewhat similar implementation.

> If this is the case then I would argue that having caching in the appserver
> is a great idea for everyone using an appserver it does not help the rest of
> the world that doesn't use an app server.

This is the consensus I'd like to see built before we spend a lot of time
on something. Heikki doesn't believe we should do this at all as it is
covered by DBCP and app server pools. You clearly believe we need this
and I'm sort of on the fence (I recall that's where Oliver is as well, but
I don't claim to speak for him).

> Is there a technical argument here ?
>

No, this is just a recap of the previous events from my perspective.

Kris Jurka

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

On 5-Sep-07, at 2:12 PM, Kris Jurka wrote:

>
>
> On Wed, 5 Sep 2007, Dave Cramer wrote:
>
>>
>> On 5-Sep-07, at 1:27 PM, Kris Jurka wrote:
>>
>>> But that benchmark was run with a different caching
>>> implementation than the wrapper version, so I'm not sure how
>>> that's relevant. When Sun chose to use unpublished and
>>> unreviewed code for the benchmark they got themselves in a little
>>> bind and I'm not sure it's our job to bail them out by publishing
>>> and advertising code that we're not confident in. Heikki,
>>> Oliver, and myself did not believe the code used by Sun in the
>>> benchmark was correct in the general case so it was rejected for
>>> inclusion in the core driver.
>>
>> So as I understand it the objection to the caching implementation
>> is that statement caching belongs in the app server ?
>
> No, the objection above is that the code you originally submitted
> was not good enough to be included in the driver regardless of
> whether it should be in the driver or app server. If we aren't
> using the code that you originally submitted then the argument that
> we need to publish something for benchmark compliance is silly
> because the requirement is you publish the code/driver used, not a
> somewhat similar implementation.

As I recall the events. The only objection to code that I submitted
for inclusion was Heikki's objection as to where caching belonged.
The proof of concept code was clearly not production and was not
meant for inclusion it was meant to generate this argument. As nobody
argued vehemently at the time I went ahead with a production version.
>
>> If this is the case then I would argue that having caching in the
>> appserver is a great idea for everyone using an appserver it does
>> not help the rest of the world that doesn't use an app server.
>
> This is the consensus I'd like to see built before we spend a lot
> of time on something. Heikki doesn't believe we should do this at
> all as it is covered by DBCP and app server pools.
Well DBCP has it's issues. It is very large and not the fastest piece
of code in the world.

> You clearly believe we need this and I'm sort of on the fence (I
> recall that's where Oliver is as well, but I don't claim to speak
> for him).



So we basically have one nay vote holding this up ?

Dave
>
>> Is there a technical argument here ?
>>
>
> No, this is just a recap of the previous events from my perspective.
>
> Kris Jurka


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly