Postgres Pro
Downloads
Home   >   mailing lists

Re: Slow performance updating CLOB data - Mailing list pgsql-jdbc

From Christopher BROWN
Subject Re: Slow performance updating CLOB data
Date
Msg-id CAHL_zcNeFZNTJ4n_2QHRCd=AzEg17DsmNQF5F+=TSoAvx8JVNA@mail.gmail.com
Whole thread Raw
In response to Re: Slow performance updating CLOB data  (Dave Cramer <pg@fastcrypt.com>)
Responses Re: Slow performance updating CLOB data  (Gavin Flower <GavinFlower@archidevsys.co.nz>)
List pgsql-jdbc
Tree view
Hello,

What would the scope and capacity of the cache be?  For example, scoped to the lifetime of a (pooled) Connection, to that of Statement, or something else, and how could the cache capacity be controlled (avoiding excessive garbage collection pressure, etc.) and instrumented (cache hits/misses, cache filling and emptying rates, etc.)?  Would it be possible for the application to issue a command to clear the cache immediately if the application is aware of structural changes (this can happen a lot in development might lead to unexpected behavior)?

--
Christopher


On 18 July 2016 at 14:38, Dave Cramer <pg@fastcrypt.com> wrote:




On 18 July 2016 at 07:48, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:
Dave>Well all drivers have to do something similar. Not all result sets are updatable. What do other drivers do ?

Technically speaking, pgjdbc could cache the names of primary keys for a given table.
It would be useful at least in two places:
1) updateable resultset
2) return generated keys

However, as of now no such cache exists in pgjdbc.
The second issue is the backend does not send notifications on DDL changes. Thus the cache can easily get out of sync when java thinks there's a column named A, and in reality the column was dropped long ago.

This error would happen far fewer times than the cache would help the problem. I think if we can figure out how to gracefully recover from the error we would be far further ahead. 


pgsql-jdbc by date:

Previous
From: Dave Cramer
Date:
Subject: Re: Slow performance updating CLOB data
Next
From: Thomas Kellerer
Date:
Subject: Re: Slow performance updating CLOB data