Re: Disk buffering of resultsets
От | Edson Richter |
---|---|
Тема | Re: Disk buffering of resultsets |
Дата | |
Msg-id | BLU436-SMTP1035AB44C7A11FB7C17BEF1CFB30@phx.gbl обсуждение исходный текст |
Ответ на | Re: Disk buffering of resultsets (Steven Schlansker <stevenschlansker@gmail.com>) |
Список | pgsql-jdbc |
Atenciosamente, Edson Carlos Ericksson Richter On 22-09-2014 14:16, Steven Schlansker wrote: > On Sep 21, 2014, at 12:35 AM, Craig Ringer <craig@2ndquadrant.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. Seems obvious, because new features like this proposal should always be off by default. +1. I've designed application architecture to overcome such limitations, and I'm really not interested in having disk cache slowing down my App server... Thanks, Edson. > > >
В списке pgsql-jdbc по дате отправления: