On Jun 15, 8:47 am, Chris Browne <cbbro...@acm.org> wrote:
> "jgard...@jonathangardner.net" <jgard...@jonathangardner.net> writes:
> > My question is how can I configure the database to run as quickly as
> > possible if I don't care about data consistency or durability? That
> > is, the data is updated so often and it can be reproduced fairly
> > rapidly so that if there is a server crash or random particles from
> > space mess up memory we'd just restart the machine and move on.
>
> For such a scenario, I'd suggest you:
>
> - Set up a filesystem that is memory-backed. On Linux, RamFS or TmpFS
> are reasonable options for this.
>
I had forgotten about this. I will try this out.
> - The complication would be that your "restart the machine and move
> on" needs to consist of quite a few steps:
>
> - recreating the filesystem
> - fixing permissions as needed
> - running initdb to set up new PG instance
> - automating any needful fiddling with postgresql.conf, pg_hba.conf
> - starting up that PG instance
> - creating users, databases, schemas, ...
>
I'm going to have a system in place to create these databases when I
restart the service.
> ...
>
> I wonder if this kind of installation "comes into its own" for more
> realistic scenarios in the presence of streaming replication. If you
> know the WAL files have gotten to disk on another server, that's a
> pretty good guarantee :-).
>
I have found that pre-computing and storing values in a general
relational-type database without durability is an ideal use case to
help improve services that need to return calculated results quickly.
A simple hash lookup is no longer sufficient. Perhaps PostgreSQL
running in this mode will be the ideal solution.
Nowadays, no one is really surprised that it takes 30 seconds or so to
replicate your data everywhere, but they do detest not getting answers
to their complicated queries immediately.