Re: Proof of concept: standalone backend with full FE/BE protocol
Andres Freund <andres@anarazel.de>
From: "anarazel@anarazel.de" <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>,Andres Freund <andres@2ndquadrant.com>
Cc: Amit Kapila <amit.kapila@huawei.com>, pgsql-hackers@postgresql.org, 'Noah Misch' <noah@leadboat.com>, hlinnaka@iki.fi
Date: 2012-09-05T15:56:33Z
Lists: pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> schrieb: >Andres Freund <andres@2ndquadrant.com> writes: >> I don't find that a convincing comparison. Normally don't need to >shutdown the >> server between two pg_dump commands. Which very well might be >scripted. > >> Especially as for now, without a background writer/checkpointer >writing stuff >> beforehand, the shutdown checkpoint won't be fast. IO isn't unlikely >if youre >> doing a pg_dump because of hint bits... > >I still think this is a straw-man argument. There is no expectation >that a standalone PG implementation would provide performance for a >series of standalone sessions that is equivalent to what you'd get from >a persistent server. If that scenario is what's important to you, >you'd >use a persistent server. The case where this sort of thing would be >interesting is where minimizing administration complexity (by not >having >a server) is more important than performance. People currently use, >eg, >SQLite for that type of application, and it's not because of >performance. I am not saying its bad that it is slower, that's absolutely OK. Just that it will take a variable amount of time till you can run pgdump again and its not easily detectable without looping and trying again. Andres --- Please excuse the brevity and formatting - I am writing this on my mobile phone.
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Remove now redundant pgpipe code.
- d2c1740dc275 9.2.0 cited