Re: Slow performance updating CLOB data

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(at)fastcrypt(dot)com> wrote:

>
>
>
>
> On 18 July 2016 at 07:48, Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)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.
>
> Dave Cramer
>
> davec(at)postgresintl(dot)com
> www.postgresintl.com
>