| From: | Steven Schlansker <stevenschlansker(at)gmail(dot)com> |
|---|---|
| To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
| Cc: | "Lussier, Denis" <denisl(at)openscg(dot)com>, Dave Cramer <pg(at)fastcrypt(dot)com>, Enrico Olivelli - Diennea <enrico(dot)olivelli(at)diennea(dot)com>, "pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org> |
| Subject: | Re: Disk buffering of resultsets |
| Date: | 2014-09-22 17:16:40 |
| Message-ID: | 3F6D0B4E-2FA9-42D0-8C2C-DC68E6D0D641@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-jdbc |
On Sep 21, 2014, at 12:35 AM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
> On 09/21/2014 11:24 AM, Lussier, Denis wrote:
>> This does seem very worthwhile. Can someone please sketch out a
>> mini-design and see if it makes sense to the pgjdbc core? I'd be
>> willing to hack some code, but, I'd want the design to be pre-vetted.
>
> Actually, on second thought, if we're going to do this we'd be silly to
> restrict it to spilling to disk.
>
> What we should have is the ability to flush a resultset to non-memory
> storage that provides a given interface when it exceeds a given size.
This all sounds very interesting, but should it really be baked into the driver?
Shouldn’t such a mechanism be built on top of the JDBC API? Then it could work
independently of the Driver implementation.
Additionally, if this does get implemented, please leave it off by default. We
have many SSDs backing our database server and very little space / IOPS on
application nodes (intentionally, and I’m not sure we are the only ones) so
suddenly spilling to disk could be disastrous for our performance.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Edson Richter | 2014-09-22 17:27:36 | Re: Disk buffering of resultsets |
| Previous Message | Stephen Nelson | 2014-09-22 13:52:34 | Re: R: Please implement simple failover scenario |