Re: Proof of concept: standalone backend with full FE/BE protocol

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: 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:47:33Z
Lists: pgsql-hackers
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.

			regards, tom lane


Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Remove now redundant pgpipe code.