From: | Dave Cramer <pg(at)fastcrypt(dot)com> |
---|---|
To: | Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com> |
Cc: | Nicola Zanaga <NZanaga(at)efsw(dot)it>, Thomas Kellerer <spam_eater(at)gmx(dot)net>, "pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: Slow performance updating CLOB data |
Date: | 2016-07-18 12:38:57 |
Message-ID: | CADK3HH+zaVhTmjgyCkYKt_RQouD1V0WeO89z0BSv7zJzoU7i=Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher BROWN | 2016-07-18 12:55:24 | Re: Slow performance updating CLOB data |
Previous Message | Nicola Zanaga | 2016-07-18 12:28:52 | R: Slow performance updating CLOB data |