Re: RFC: Async query processing

From: Florian Weimer <fweimer(at)redhat(dot)com>
To: Craig Ringer <craig(at)2ndquadrant(dot)com>, Claudio Freire <klaussfreire(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-Dev <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RFC: Async query processing
Date: 2014-04-22 11:19:02
Message-ID: 53565026.9070807@redhat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 01/05/2014 01:56 PM, Craig Ringer wrote:

> JDBC also has a statement batching interface. Right now PgJDBC just
> unwraps the batch and runs each query individually. Any async-support
> improvements server-side should probably consider the need of executing
> a batch. The batch might be one PreparedStatement with many different
> parameters, or it might be a series of unrelated statements. A way for
> PgJDBC to run the batch without syncing with the server after each query
> would be really helpful.

The server already supports this because it supports pipelining.

Anyway, I have now switched my application to COPY FROM STDIN where
possible, and the increase in throughput is phenomenal—even though it is
running completely locally. I could squeeze out more round-trips if I
had an asynchronous query facility in libpq.

Feedback in this thread was, "we want something like this in libpq, but
not the thing you proposed". But there have been no concrete
counter-proposals, and some of the responses did not take into account
the inherent complexities of round-trip avoidance. So I'm not sure how
to move this topic forward.

--
Florian Weimer / Red Hat Product Security Team

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Honza 2014-04-22 11:19:15 Re: Store data in pg_toast for custom type fails (bug?)
Previous Message Jov 2014-04-22 09:42:37 Re: AXLE Plans for 9.5 and 9.6