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 →
  1. Remove now redundant pgpipe code.