Re: Disk buffering of resultsets

I agree that this possible new feature would definitely be off by default.

I like Craig's idea to use the jdk7 temp file handling. I propose to this
project keep it simple (at least at first) and start with this as a jdbc41
only feature.

Many people use pgjdbc for OLTP style transactions and wouldn't ever want
to spill to disk. This is why (IMHO) the algorithm that determines under
which stress
condition this feature uses (assuming it is enabled) is so critical.

On Mon, Sep 22, 2014 at 1:42 PM, John R Pierce <pierce(at)hogranch(dot)com> wrote:

> On 9/22/2014 10:16 AM, Steven Schlansker wrote:
>
>> 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.
>>
>
> we have a high volume messaging subsystem that normally uses no disk, but
> if a subscriber goes offline, it spools to disk, then when the subscriber
> comes back, it plays back those spools. its designed this way, its
> advertised as working this way, we require high performance dedicated RAID
> storage on the messaging box for these spools.... time and time again
> operations has seen it happily hum along for 6 months with no disk IO
> usage, and push it onto 2nd/3rd tier storage to free up the 1st tier for
> something else. then a subscriber goes offline for 14 hours, and the
> system just croaks and can't keep up.
>
>
>
> --
> john r pierce 37N 122W
> somewhere on the middle of the left coast
>
>
>
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc
>