| From: | Greg Stark <stark(at)mit(dot)edu> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Claudio Freire <klaussfreire(at)gmail(dot)com>, Florian Weimer <fweimer(at)redhat(dot)com>, PostgreSQL-Dev <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: RFC: Async query processing |
| Date: | 2014-01-05 14:11:51 |
| Message-ID: | CAM-w4HMqeqKS19HSXnvOGYr8=pOLD7iYdzz_S2MxGyG_VqcSkQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Jan 3, 2014 at 3:20 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I think Florian has a good point there, and the reason is this: what
> you are talking about will be of exactly zero use to applications that
> want to see the results of one query before launching the next.
There are techniques for handling that actually. For a better
explanation than I can do see
http://kentonv.github.io/capnproto/rpc.html. It's mostly a language
feature but it does require support from the protocol to be able to
reference data in earlier responses in your subsequent requests.
You can pull this trick by having an RPC server near the database so
all the latency is handled by the RPC server and not the database
connection. But it seems to me that that's unnecessary complication
and shouldn't be necessary. The database protocol basically is an RPC
layer.
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Florian Weimer | 2014-01-05 15:57:06 | Re: RFC: Async query processing |
| Previous Message | Craig Ringer | 2014-01-05 13:09:59 | Re: RFC: Async query processing |