From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Amit Kapila <amit(dot)kapila(at)huawei(dot)com>, pgsql-hackers(at)postgresql(dot)org, "'Noah Misch'" <noah(at)leadboat(dot)com>, hlinnaka(at)iki(dot)fi |
Subject: | Re: Proof of concept: standalone backend with full FE/BE protocol |
Date: | 2012-09-05 15:47:33 |
Message-ID: | 17839.1346860053@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | anarazel@anarazel.de | 2012-09-05 15:56:33 | Re: Proof of concept: standalone backend with full FE/BE protocol |
Previous Message | Andres Freund | 2012-09-05 15:31:53 | Re: Proof of concept: standalone backend with full FE/BE protocol |