| From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
|---|---|
| To: | Merlin Moncure <mmoncure(at)gmail(dot)com>, Claudio Freire <klaussfreire(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 13:09:59 |
| Message-ID: | 52C959A7.5040401@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 01/04/2014 01:22 AM, Merlin Moncure wrote:
> Long term, I'd rather see an optimized 'ORM flush' assemble the data
> into a structured data set (perhaps a JSON document) and pass it to
> some receiving routine that decomposed it into records.
The same is true on the input side. I'd much rather be sending an ORM
client a big JSON / YAML / whatever graph than a horrible,
duplication-filled chained LEFT JOIN projection like they currently rely
on. When they're not just doing n+1 selects, which is worse.
I think that's really a side-issue though. ORMs aren't going to change
in a hurry, and batching / fire-and-forget support is good for all sorts
of other jobs too.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Stark | 2014-01-05 14:11:51 | Re: RFC: Async query processing |
| Previous Message | Craig Ringer | 2014-01-05 12:56:30 | Re: RFC: Async query processing |