Re: Proof of concept: standalone backend with full FE/BE protocol - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Proof of concept: standalone backend with full FE/BE protocol
Date
Msg-id 201209072322.49633.andres@2ndquadrant.com
Whole thread Raw
In response to Re: Proof of concept: standalone backend with full FE/BE protocol  (Merlin Moncure <mmoncure@gmail.com>)
List 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



pgsql-hackers by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: Proof of concept: standalone backend with full FE/BE protocol
Next
From: Jim Nasby
Date:
Subject: Re: Proof of concept: standalone backend with full FE/BE protocol