Re: Proof of concept: standalone backend with full FE/BE protocol
От | Josh Berkus |
---|---|
Тема | Re: Proof of concept: standalone backend with full FE/BE protocol |
Дата | |
Msg-id | 5047D29D.6030901@agliodbs.com обсуждение исходный текст |
Ответ на | Re: Proof of concept: standalone backend with full FE/BE protocol (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Proof of concept: standalone backend with full FE/BE protocol
|
Список | pgsql-hackers |
> Um ... true with respect to autovacuum, perhaps, but what about > checkpoints? A standalone backend will never perform a checkpoint > unless explicitly told to. Hmmm, that's definitely an issue. > (Before we invented the bgwriter, the > postmaster was in charge of launching checkpoints every so often.) > Again, this is probably just what you want for disaster recovery, but > it wouldn't be terribly friendly for an embedded-database application. Yeah, we'd have to put in a clock-based thing which did checkpoints every 5 minutes and VACUUM ANALYZE every hour or something. That seems like a chunk of extra code. > In general I think the selling point for such a feature would be "no > administrative hassles", and I believe that has to go not only for the > end-user experience but also for the application-developer experience. > If you have to manage checkpointing and vacuuming in the application, > you're probably soon going to look for another database. Well, don't discount the development/testing case. If you do agile or TDD (a lot of people do), you often have a workload which looks like: 1) Start framework 2) Start database 3) Load database with test data 4) Run tests 5) Print results 6) Shut down database In a case like that, you can live without checkpointing, even; the database is ephemeral. In other words, let's make this a feature and document it for use in testing, and that it's not really usable for production embedded apps yet. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
В списке pgsql-hackers по дате отправления: