Thread: Speed up fixes

Hello,

Unfortunately JDBC drivers for PostgreSQL are always in hot spots on
heavy database usage. I've looked through and fixed 2-3 obvious
performance leaks which saves 20-30% CPU usage percents for our
application. If you are interested please review and commit to your
source tree. See attached diff file for version 8.0.316.

Thanks,
  -- Sergei Rogovskiy
Brightech Inc.

Interestingly we've had two people provide exactly (more or less )
the same patch in as many weeks.

thanks

Dave
On 21-Oct-05, at 11:57 AM, Sergei Rogovskiy wrote:

> Hello,
>
> Unfortunately JDBC drivers for PostgreSQL are always in hot spots
> on heavy database usage. I've looked through and fixed 2-3 obvious
> performance leaks which saves 20-30% CPU usage percents for our
> application. If you are interested please review and commit to your
> source tree. See attached diff file for version 8.0.316.
>
> Thanks,
>  -- Sergei Rogovskiy
> Brightech Inc.
>
>
> <speedup.patch>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
>                http://www.postgresql.org/docs/faq
>

Sergei.

I understand everything except the removal of replaceProcessingEnabled ?

please explain.

Dave
On 21-Oct-05, at 11:57 AM, Sergei Rogovskiy wrote:

> Hello,
>
> Unfortunately JDBC drivers for PostgreSQL are always in hot spots
> on heavy database usage. I've looked through and fixed 2-3 obvious
> performance leaks which saves 20-30% CPU usage percents for our
> application. If you are interested please review and commit to your
> source tree. See attached diff file for version 8.0.316.
>
> Thanks,
>  -- Sergei Rogovskiy
> Brightech Inc.
>
>
> <speedup.patch>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
>                http://www.postgresql.org/docs/faq
>

Dave Cramer wrote:

> I understand everything except the removal of replaceProcessingEnabled ?

His diff was reversed by the looks of it, so that's actually new code.

It looks like he is adding a new connection property
"replaceProcessingEnabled" which lets you disable escape processing for
all statements. I'm not convinced we want this, as when enabled we
wouldn't follow the JDBC spec.

Sergei, can you send through whatever profiling results that show that
replace processing is a hotspot? Maybe we can speed up the no-escapes
case, rather than disabling them altogether which seems like a bit of a
blunt instrument..

-O

I'm applying the others plus Ken Gries' patches as well. I'm not
applying the escape processing one yet.

Dave
On 24-Oct-05, at 4:31 PM, Oliver Jowett wrote:

> Dave Cramer wrote:
>
>
>> I understand everything except the removal of
>> replaceProcessingEnabled ?
>>
>
> His diff was reversed by the looks of it, so that's actually new code.
>
> It looks like he is adding a new connection property
> "replaceProcessingEnabled" which lets you disable escape processing
> for all statements. I'm not convinced we want this, as when enabled
> we wouldn't follow the JDBC spec.
>
> Sergei, can you send through whatever profiling results that show
> that replace processing is a hotspot? Maybe we can speed up the no-
> escapes case, rather than disabling them altogether which seems
> like a bit of a blunt instrument..
>
> -O
>
>