Re: Parallell Optimizer - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Parallell Optimizer
Date
Msg-id 20130613015306.GH7200@tamriel.snowman.net
Whole thread Raw
In response to Re: Parallell Optimizer  (Ants Aasma <ants.aasma@eesti.ee>)
List pgsql-hackers
Ants,

* Ants Aasma (ants.aasma@eesti.ee) wrote:
> On Jun 13, 2013 4:18 AM, "Stephen Frost" <sfrost@snowman.net> wrote:
> > * Ants Aasma (ants@cybertec.at) wrote:
> > > In a cluster setting you take the CSN value on the master, then before
> > > starting execution on a standby you wait until that the standby has
> > > replayed enough WAL to reach the CSN point read from the master and
> > > you know that after that everything that the snapshot can see is also
> > > replayed on the standby.
> >
> > This does make a lot of sense- but to clarify, this would only be for
> > certain isolation levels, right?  Or would we implement this for every
> > snapshot taken in a read-committed transaction?
>
> I don't see a way how snapshots representing different points in time could
> provide sensible results for parallel queries, so this needs to be used for
> all snapshots.

To be honest, I had really looked at this out of context and was
thinking of it being used with replication and hot-standbys.  I agree
that you'd have to use this for all snapshots if you're using it for
parallel query execution.

> This is why having the capability to request for a snapshot
> that is fresh enough for a specific client but old enough to not require
> replication waits would be a good feature.

That's an interesting concept.
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Ants Aasma
Date:
Subject: Re: Parallell Optimizer
Next
From: Darren Duncan
Date:
Subject: Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: Should array_length() Return NULL)