| 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: | Whole Thread | Raw Message | 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 |