On Thu, Jun 13, 2013 at 11:24 AM, Simon Riggs wrote:
> That idea is not dependent upon CSNs.
>
> It is an option for us to implement snapshot synchronisation now, we
> just haven't done it yet.
>
> I'm currently working on exporting/importing snapshots on standbys,
> which is a precursor to that i
On Thu, Jun 13, 2013 at 11:39 AM, Hannu Krosing wrote:
>>> Coincidentally getting cluster wide consistent snapshots and delaying
>>> until some specific point in commit ordering is almost trivial to
>>> solve with Commit Sequence Number based snapshot scheme that I
>>> proposed.
>> Can you elabora
On 06/13/2013 02:22 AM, Tatsuo Ishii wrote:
>> On Jun 12, 2013 2:02 AM, "Tatsuo Ishii" wrote:
>>> No, I'm not talking about conflict resolution.
>>>
>>> From
>>> http://www.cs.cmu.edu/~natassa/courses/15-823/F02/papers/replication.pdf:
>>> --
>>> Eager
On 13 June 2013 02:18, Stephen Frost wrote:
> * Ants Aasma (a...@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 a
On 11 June 2013 15:59, Tatsuo Ishii wrote:
> I wonder why "true" synchronous replication nor "eager replication"
> are not in the developer TODO list. If we want them in the future,
> they should be on it.
I think you still need to explain what "true" synchronous replication is.
IMHO eager repl
Ants,
* Ants Aasma (ants.aa...@eesti.ee) wrote:
> On Jun 13, 2013 4:18 AM, "Stephen Frost" wrote:
> > * Ants Aasma (a...@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
> > >
On Jun 13, 2013 4:18 AM, "Stephen Frost" wrote:
> * Ants Aasma (a...@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 m
* Ants Aasma (a...@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
> On Thu, Jun 13, 2013 at 3:22 AM, Tatsuo Ishii wrote:
>>> Parallel query execution doesn't require commits to synchronize all
>>> nodes. Parallel execution needs consistent snapshots across all nodes.
>>> In effect this means that nodes need to agree on commit ordering,
>>> either total order or
On Thu, Jun 13, 2013 at 3:22 AM, Tatsuo Ishii wrote:
>> Parallel query execution doesn't require commits to synchronize all
>> nodes. Parallel execution needs consistent snapshots across all nodes.
>> In effect this means that nodes need to agree on commit ordering,
>> either total order or a part
> On Jun 12, 2013 2:02 AM, "Tatsuo Ishii" wrote:
>> No, I'm not talking about conflict resolution.
>>
>> From
>> http://www.cs.cmu.edu/~natassa/courses/15-823/F02/papers/replication.pdf:
>> --
>> Eager or Lazy Replication?
>> Eager replication:
>> kee
On Jun 12, 2013 2:02 AM, "Tatsuo Ishii" wrote:
> No, I'm not talking about conflict resolution.
>
> From http://www.cs.cmu.edu/~natassa/courses/15-823/F02/papers/replication.pdf:
> --
> Eager or Lazy Replication?
> Eager replication:
> keep all replica
On 2013-06-07 19:09, Fred&Dani&Pandora&Aquiles wrote:
I asked a while ago in this group about the possibility to implement a
parallel planner in a multithread way, and the replies were that the
proposed approach couldn't be implemented, because the postgres is not
thread-safe. With the new fea
On 06/12/2013 07:01 AM, Tatsuo Ishii wrote:
Please explain what you mean by the word "true" used here.
>>> In another word, "eager replication".
>> Do you mean something along these lines :
>>
>> "Most synchronous or eager replication solutions do conflict prevention,
>> while asynchronous sol
>> No, I'm not talking about conflict resolution.
>>
>> From
>> http://www.cs.cmu.edu/~natassa/courses/15-823/F02/papers/replication.pdf:
>> --
>> Eager or Lazy Replication?
>> Eager replication:
>> keep all replicas synchronized by updating all
>> re
On 06/12/2013 01:01 AM, Tatsuo Ishii wrote:
Please explain what you mean by the word "true" used here.
>>> In another word, "eager replication".
>> Do you mean something along these lines :
>>
>> "Most synchronous or eager replication solutions do conflict prevention,
>> while asynchronous sol
>>> Please explain what you mean by the word "true" used here.
>> In another word, "eager replication".
> Do you mean something along these lines :
>
> "Most synchronous or eager replication solutions do conflict prevention,
> while asynchronous solutions have to do conflict resolution. For instan
On 06/11/2013 04:53 PM, Tatsuo Ishii wrote:
>> On 11 June 2013 01:45, Tatsuo Ishii wrote:
On Sat, Jun 8, 2013 at 5:04 AM, Simon Riggs wrote:
> On 7 June 2013 20:23, Tom Lane wrote:
>
>> As for other databases, I suspect that ones that have parallel execution
>> are prob
On 11/06/13 19:24, Hannu Krosing wrote:
On 06/10/2013 10:37 PM, Fred&Dani&Pandora&Aquiles wrote:
Hi,
>> I asked a while ago in this group about the possibility to
implement a
>> parallel planner in a multithread way, and the replies were
that the
>> proposed approach couldn
On 6/7/13 2:23 PM, Tom Lane wrote:
As for other databases, I suspect that ones that have parallel execution
are probably doing it with a thread model not a process model.
Oracle 9i was multi-process, not multi-threaded. IIRC it actually had dedicated
IO processes too; backends didn't do their
> On Tue, Jun 11, 2013 at 9:45 AM, Tatsuo Ishii wrote:
>
>> > On Sat, Jun 8, 2013 at 5:04 AM, Simon Riggs
>> wrote:
>> >
>> >> On 7 June 2013 20:23, Tom Lane wrote:
>> >>
>> >> > As for other databases, I suspect that ones that have parallel
>> execution
>> >> > are probably doing it with a thr
> On 11 June 2013 01:45, Tatsuo Ishii wrote:
>>> On Sat, Jun 8, 2013 at 5:04 AM, Simon Riggs wrote:
>>>
On 7 June 2013 20:23, Tom Lane wrote:
> As for other databases, I suspect that ones that have parallel execution
> are probably doing it with a thread model not a process m
On 06/10/2013 10:37 PM, Fred&Dani&Pandora&Aquiles wrote:
> Hi,
>
>
> >> I asked a while ago in this group about the possibility to
> implement a
> >> parallel planner in a multithread way, and the replies were
> that the
> >> proposed approach couldn't be implemented, because
On 11 June 2013 01:45, Tatsuo Ishii wrote:
>> On Sat, Jun 8, 2013 at 5:04 AM, Simon Riggs wrote:
>>
>>> On 7 June 2013 20:23, Tom Lane wrote:
>>>
>>> > As for other databases, I suspect that ones that have parallel execution
>>> > are probably doing it with a thread model not a process model.
>>
On Tue, Jun 11, 2013 at 9:45 AM, Tatsuo Ishii wrote:
> > On Sat, Jun 8, 2013 at 5:04 AM, Simon Riggs
> wrote:
> >
> >> On 7 June 2013 20:23, Tom Lane wrote:
> >>
> >> > As for other databases, I suspect that ones that have parallel
> execution
> >> > are probably doing it with a thread model no
> On Sat, Jun 8, 2013 at 5:04 AM, Simon Riggs wrote:
>
>> On 7 June 2013 20:23, Tom Lane wrote:
>>
>> > As for other databases, I suspect that ones that have parallel execution
>> > are probably doing it with a thread model not a process model.
>>
>> Separate processes are more common because it
On Sat, Jun 8, 2013 at 5:04 AM, Simon Riggs wrote:
> On 7 June 2013 20:23, Tom Lane wrote:
>
> > As for other databases, I suspect that ones that have parallel execution
> > are probably doing it with a thread model not a process model.
>
> Separate processes are more common because it covers th
Hi,
> >> I asked a while ago in this group about the possibility to implement a
> >> parallel planner in a multithread way, and the replies were that the
> >> proposed approach couldn't be implemented, because the postgres is not
> >> thread-safe. With the new feature Background Worker Processes
On 7 June 2013 20:23, Tom Lane wrote:
> As for other databases, I suspect that ones that have parallel execution
> are probably doing it with a thread model not a process model.
Separate processes are more common because it covers the general case
where query execution is spread across multiple
On Fri, Jun 7, 2013 at 3:23 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jun 7, 2013 at 2:27 PM, Tom Lane wrote:
>>> I don't think that bgworkers as currently implemented make this any more
>>> practical than it was before. The communication overhead with a
>>> separate process would sw
Robert Haas writes:
> On Fri, Jun 7, 2013 at 2:27 PM, Tom Lane wrote:
>> I don't think that bgworkers as currently implemented make this any more
>> practical than it was before. The communication overhead with a
>> separate process would swamp any benefit in most cases.
> I'm baffled by your s
On Fri, Jun 7, 2013 at 2:27 PM, Tom Lane wrote:
> "Fred&Dani&Pandora&Aquiles" writes:
>> I asked a while ago in this group about the possibility to implement a
>> parallel planner in a multithread way, and the replies were that the
>> proposed approach couldn't be implemented, because the postgr
"Fred&Dani&Pandora&Aquiles" writes:
> I asked a while ago in this group about the possibility to implement a
> parallel planner in a multithread way, and the replies were that the
> proposed approach couldn't be implemented, because the postgres is not
> thread-safe. With the new feature Backgrou
I asked a while ago in this group about the possibility to implement a
parallel planner in a multithread way, and the replies were that the
proposed approach couldn't be implemented, because the postgres is not
thread-safe. With the new feature Background Worker Processes, such
implementation woul
34 matches
Mail list logo
