Re: Proof of concept: standalone backend with full FE/BE protocol

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Proof of concept: standalone backend with full FE/BE protocol
Date: 2012-09-07 21:21:00
Message-ID: CAHyXU0y9V+=P92iTJMWaBgJcz4Nd24T_ApAb6QooUtCxNjU6xQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 6, 2012 at 12:56 PM, Jeff Davis <pgsql(at)j-davis(dot)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.

merlin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2012-09-07 21:22:49 Re: Proof of concept: standalone backend with full FE/BE protocol
Previous Message Tom Lane 2012-09-07 20:10:15 Re: Proof of concept: standalone backend with full FE/BE protocol