Re: Proof of concept: standalone backend with full FE/BE protocol
Andres Freund <andres@2ndquadrant.com>
From: Andres Freund <andres@2ndquadrant.com>
To: pgsql-hackers@postgresql.org
Cc: Merlin Moncure <mmoncure@gmail.com>, Jeff Davis <pgsql@j-davis.com>, Tom Lane <tgl@sss.pgh.pa.us>, Josh Berkus <josh@agliodbs.com>
Date: 2012-09-07T21:22:49Z
Lists: pgsql-hackers
On Friday, September 07, 2012 11:21:00 PM Merlin Moncure wrote: > On Thu, Sep 6, 2012 at 12:56 PM, Jeff Davis <pgsql@j-davis.com> wrote: > > On Wed, 2012-09-05 at 17:03 -0400, Tom Lane wrote: > >> 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. > > > > Maybe there could be some hooks (e.g., right after completing a > > statement) that see whether a vacuum or checkpoint is required? VACUUM > > can't be run in a transaction block[1], so there are some details to > > work out, but it might be a workable approach. > > If it was me, I'd want finer grained control of if/when automatic > background optimization work happened. Something like > DoBackgroundWork(int forThisManySeconds). Of course, for that to > work, we'd need to have resumable vacuum. > > I like the idea of keeping everything single threaded. To me this path seems to be the best way to never get the feature at all... Andres -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Remove now redundant pgpipe code.
- d2c1740dc275 9.2.0 cited