On Fri, May 4, 2012 at 12:59 PM, Andres Freund wrote:
> In my understanding - as the person doing quite a bit of the coding atm - the
> point is to provide a very minimal *early* prototype to have a sensible basis
> for design decisions/discussions. On one side thats useful to get a feeling
> for
Hi Robert, Hi all,
On Friday, May 04, 2012 06:29:33 PM Robert Haas wrote:
> On Fri, May 4, 2012 at 11:06 AM, Greg Smith wrote:
> > The straw man argument here would require 100% transparency on everything
> > you do in regards to PostgreSQL and related software. Before doing any
> > development
On Fri, May 4, 2012 at 11:06 AM, Greg Smith wrote:
> The straw man argument here would require 100% transparency on everything
> you do in regards to PostgreSQL and related software. Before doing any
> development on any code, first post here to ask for design review. And if
> someone asks you t
On 05/04/2012 09:03 AM, Robert Haas wrote:
I try pretty hard not to go off and do large amounts of work in a
vacuum. If something is more than a couple days work, I post the
design on hackers and wait for feedback before writing a line of code.
That is an excellent luxury to have. You've work
On 4 May 2012 14:01, Robert Haas wrote:
> On Fri, May 4, 2012 at 8:32 AM, Hannu Krosing wrote:
>> For logical we don't really need to uniquely identify such rows - it
>> should sufficient if we just update exactly one of the matching rows.
>>
>> The way to do this is to put all fields of the OLD.
On Thu, May 3, 2012 at 8:22 PM, Greg Smith wrote:
> On 05/01/2012 09:09 AM, Robert Haas wrote:
>>
>> I think we ought to be sharing and debugging designs in
>> public, not internally within 2ndQuadrant - or any other company, or
>> any other mailing list other than this one.
>
> OK. You go first.
On Fri, May 4, 2012 at 8:32 AM, Hannu Krosing wrote:
> For logical we don't really need to uniquely identify such rows - it
> should sufficient if we just update exactly one of the matching rows.
>
> The way to do this is to put all fields of the OLD.* tuple in the WHERE
> clause and then update j
On Thu, 2012-05-03 at 00:58 -0500, Jim Nasby wrote:
> On 4/29/12 6:03 AM, Simon Riggs wrote:
> >> The DML-WITH-LIMIT-1 is required to do single logical updates on tables
> >> > with non-unique rows.
> >> > And as for any logical updates we will have huge performance problem
> >> > when doing UPD
On 05/01/2012 09:09 AM, Robert Haas wrote:
I think we ought to be sharing and debugging designs in
public, not internally within 2ndQuadrant - or any other company, or
any other mailing list other than this one.
OK. You go first.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltim
On Thu, May 3, 2012 at 6:03 PM, Josh Berkus wrote:
> I do agree that depending on user-defined PKs raises a whole host of
> issues which we'd rather just sidestep, though.
What do you have in mind instead?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 2
> Something that a in-core method might be able to do that an external one
> can't would be to support a method of uniquely identifying rows in
> tables with no PK's. A gross example (that undoubtedly wouldn't work in
> the real world) would be using TID's. A real-world implementation might
> be b
On 5/2/12 10:58 PM, Jim Nasby wrote:
> On 4/29/12 6:03 AM, Simon Riggs wrote:
>>> The DML-WITH-LIMIT-1 is required to do single logical updates on tables
>>> > with non-unique rows.
>>> > And as for any logical updates we will have huge performance problem
>>> > when doing UPDATE or DELETE on la
On 4/29/12 6:03 AM, Simon Riggs wrote:
The DML-WITH-LIMIT-1 is required to do single logical updates on tables
> with non-unique rows.
> And as for any logical updates we will have huge performance problem
> when doing UPDATE or DELETE on large table with no indexes, but
> fortunately this pr
On Tue, May 1, 2012 at 2:09 PM, Robert Haas wrote:
> One thing I am a bit uncomfortable with about this whole discussion is
> that it seems like a lot of the design and research is happening
> off-list, with intent to report results back here later. While that
> is obviously fine at some level,
On Mon, Apr 30, 2012 at 6:43 PM, Josh Berkus wrote:
> Well, this *is* the purpose of the cluster-hackers group, to add backend
> support which would make external replication systems easier to build
> and more efficient. So far the only real feature to come out of that
> has been the Command Trig
On Tue, May 1, 2012 at 1:10 AM, Tatsuo Ishii wrote:
>> Those are the basic requirements that I am trying to address. There
>> are a great many important details, but the core of this is probably
>> what I would call "logical replication", that is shipping changes to
>> other nodes in a way that do
> Those are the basic requirements that I am trying to address. There
> are a great many important details, but the core of this is probably
> what I would call "logical replication", that is shipping changes to
> other nodes in a way that does not tie us to the same physical
> representation that
>> Well, this *is* the purpose of the cluster-hackers group
>
> Well, I tried all available means to discuss my ideas before
> organising an external meeting. You can think of the InCore meeting as
> an extension of the cluster hackers meeting if you wish.
That comment wasn't for you, it was for
On Mon, Apr 30, 2012 at 11:43 PM, Josh Berkus wrote:
> Well, this *is* the purpose of the cluster-hackers group
Well, I tried all available means to discuss my ideas before
organising an external meeting. You can think of the InCore meeting as
an extension of the cluster hackers meeting if you w
>> If we just had that much in core - that is, the ability to efficiently
>> extra tuple inserts, updates, and deletes on a logical level - it
>> would be much easier to build a good logical replication system around
>> PostgreSQL than it is today, and the existing systems could be adapted
>> to d
On Mon, Apr 30, 2012 at 2:38 PM, Robert Haas wrote:
> On Mon, Apr 30, 2012 at 2:33 PM, Merlin Moncure wrote:
>> On Mon, Apr 30, 2012 at 12:38 PM, Bruce Momjian wrote:
>>> For example, you said that "MM replication alone is not a solution for
>>> large data or the general case". Why is that? Is
Robert Haas wrote:
> The other half of the changes - applying the updates - is
> relatively straightforward, and it wouldn't bother me to leave
> that in user-land, especially in the MMR case, where you have to
> deal with conflict resolution rules that may be much simpler to
> express in a high
On Mon, Apr 30, 2012 at 07:55:00PM +0100, Simon Riggs wrote:
> On Mon, Apr 30, 2012 at 6:38 PM, Bruce Momjian wrote:
>
> > I would love to see a layout of exactly where these things make sense,
> > similar to what we do at the bottom of our documentation for "High
> > Availability, Load Balancing
On Mon, Apr 30, 2012 at 2:33 PM, Merlin Moncure wrote:
> On Mon, Apr 30, 2012 at 12:38 PM, Bruce Momjian wrote:
>> For example, you said that "MM replication alone is not a solution for
>> large data or the general case". Why is that? Is the goal of your work
>> really to do logical replciation
On Mon, Apr 30, 2012 at 6:38 PM, Bruce Momjian wrote:
> I would love to see a layout of exactly where these things make sense,
> similar to what we do at the bottom of our documentation for "High
> Availability, Load Balancing, and Replication":
>
>
> http://www.postgresql.org/docs/9.1/st
On Mon, Apr 30, 2012 at 12:38 PM, Bruce Momjian wrote:
> For example, you said that "MM replication alone is not a solution for
> large data or the general case". Why is that? Is the goal of your work
> really to do logical replciation, which allows for major version
> upgrades? Is that the def
On Thu, Apr 26, 2012 at 01:41:33PM +0100, Simon Riggs wrote:
> Some people have talked about the need for "multi-master replication",
> whereby 2+ databases communicate changes to one another. This topic
> has been discussed in some depth in Computer Science academic papers,
> most notably, "The Da
On Mon, Apr 30, 2012 at 12:39 PM, Simon Riggs wrote:
> On Mon, Apr 30, 2012 at 7:35 AM, Dave Page wrote:
>> On Sun, Apr 29, 2012 at 11:20 PM, Alvaro Herrera
>> wrote:
>>>
>>> Excerpts from Simon Riggs's message of jue abr 26 11:10:09 -0300 2012:
On Thu, Apr 26, 2012 at 1:41 PM, Simon Riggs
On Mon, Apr 30, 2012 at 7:35 AM, Dave Page wrote:
> On Sun, Apr 29, 2012 at 11:20 PM, Alvaro Herrera
> wrote:
>>
>> Excerpts from Simon Riggs's message of jue abr 26 11:10:09 -0300 2012:
>>> On Thu, Apr 26, 2012 at 1:41 PM, Simon Riggs wrote:
>>>
>>> > I will also be organising a small-medium si
On Sun, Apr 29, 2012 at 11:20 PM, Alvaro Herrera
wrote:
>
> Excerpts from Simon Riggs's message of jue abr 26 11:10:09 -0300 2012:
>> On Thu, Apr 26, 2012 at 1:41 PM, Simon Riggs wrote:
>>
>> > I will also be organising a small-medium sized "Future of In-Core
>> > Replication" meeting in Ottawa o
Excerpts from Simon Riggs's message of jue abr 26 11:10:09 -0300 2012:
> On Thu, Apr 26, 2012 at 1:41 PM, Simon Riggs wrote:
>
> > I will also be organising a small-medium sized "Future of In-Core
> > Replication" meeting in Ottawa on Wed 16 May, 6-10pm.
>
> Thanks for such rapid response. I've
On Sun, Apr 29, 2012 at 6:20 PM, Hannu Krosing wrote:
> On Sun, 2012-04-29 at 12:03 +0100, Simon Riggs wrote:
>> On Sat, Apr 28, 2012 at 8:40 PM, Hannu Krosing wrote:
>>
>> > As to what LCRs should contain, it will probably be locical equivalents
>> > of INSERT, UPDATE ... LIMIT 1, DELETE ... LIM
On Sun, 2012-04-29 at 12:03 +0100, Simon Riggs wrote:
> On Sat, Apr 28, 2012 at 8:40 PM, Hannu Krosing wrote:
>
> > As to what LCRs should contain, it will probably be locical equivalents
> > of INSERT, UPDATE ... LIMIT 1, DELETE ... LIMIT 1, TRUNCATE and all DDL.
>
> Yeh
>
> > I would even go
On Sat, Apr 28, 2012 at 8:40 PM, Hannu Krosing wrote:
> As to what LCRs should contain, it will probably be locical equivalents
> of INSERT, UPDATE ... LIMIT 1, DELETE ... LIMIT 1, TRUNCATE and all DDL.
Yeh
> I would even go as far as propose a variant for DML-WITH-LIMIT-1 to be
> added to post
On Sat, 2012-04-28 at 21:40 +0200, Hannu Krosing wrote:
> On Sat, 2012-04-28 at 09:36 +0100, Simon Riggs wrote:
> > On Fri, Apr 27, 2012 at 11:50 PM, Christopher Browne
> > wrote:
> > > On Fri, Apr 27, 2012 at 4:11 AM, Simon Riggs
> > > wrote:
> > >> What I'm hoping to do is to build a basic pr
On Sat, 2012-04-28 at 09:36 +0100, Simon Riggs wrote:
> On Fri, Apr 27, 2012 at 11:50 PM, Christopher Browne
> wrote:
> > On Fri, Apr 27, 2012 at 4:11 AM, Simon Riggs wrote:
> >> What I'm hoping to do is to build a basic prototype of logical
> >> replication using WAL translation, so we can insp
On Fri, Apr 27, 2012 at 11:50 PM, Christopher Browne wrote:
> On Fri, Apr 27, 2012 at 4:11 AM, Simon Riggs wrote:
>> What I'm hoping to do is to build a basic prototype of logical
>> replication using WAL translation, so we can inspect it to see what
>> the downsides are. It's an extremely non-tr
On Fri, Apr 27, 2012 at 4:11 AM, Simon Riggs wrote:
> What I'm hoping to do is to build a basic prototype of logical
> replication using WAL translation, so we can inspect it to see what
> the downsides are. It's an extremely non-trivial problem and so I
> expect there to be mountains to climb. Th
On 04/27/2012 11:33 AM, Simon Riggs wrote:
Well, they all sound similar. My info was that Mammoth was not WAL-based.
Mammoth was transaction log based but not WAL based.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postg
On Fri, Apr 27, 2012 at 6:59 PM, Josh Berkus wrote:
>
>> What I'm hoping to do is to build a basic prototype of logical
>> replication using WAL translation, so we can inspect it to see what
>> the downsides are.
>
> Sounds like Mammoth. You take a look at that?
Well, they all sound similar. My
> What I'm hoping to do is to build a basic prototype of logical
> replication using WAL translation, so we can inspect it to see what
> the downsides are.
Sounds like Mammoth. You take a look at that?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mai
On Fri, Apr 27, 2012 at 12:40 AM, Robert Haas wrote:
> On Thu, Apr 26, 2012 at 6:48 PM, Josh Berkus wrote:
>> So the idea is that you'll present briefly your intentions for 9.3 at
>> the developer meeting, and then have this in-depth afterwards? Sounds
>> great.
>
> I really, really do not want
On Fri, Apr 27, 2012 at 1:26 AM, Josh Berkus wrote:
> Simon,
>
>> I'm beginning to work on advanced additions to in-core replication for
>> PostgreSQL.
> ...
>> Those are the basic requirements that I am trying to address. There
>> are a great many important details, but the core of this is probab
Simon,
> I'm beginning to work on advanced additions to in-core replication for
> PostgreSQL.
...
> Those are the basic requirements that I am trying to address. There
> are a great many important details, but the core of this is probably
> what I would call "logical replication", that is shipping
On Thu, Apr 26, 2012 at 6:48 PM, Josh Berkus wrote:
> So the idea is that you'll present briefly your intentions for 9.3 at
> the developer meeting, and then have this in-depth afterwards? Sounds
> great.
I really, really do not want the developer meeting to turn into a
series of presentations.
Simon,
So the idea is that you'll present briefly your intentions for 9.3 at
the developer meeting, and then have this in-depth afterwards? Sounds
great.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
On 4/26/12 7:41 AM, Simon Riggs wrote:
5. WRITE-SCALEABLE - the ability to partition data across nodes in a
way that allows the solution to improve beyond the write rate of a
single node.
It would be valuable to look at READ-SCALEABLE as well; specifically a second form of
"synchronous" replic
On Thu, Apr 26, 2012 at 1:41 PM, Simon Riggs wrote:
> I will also be organising a small-medium sized "Future of In-Core
> Replication" meeting in Ottawa on Wed 16 May, 6-10pm.
Thanks for such rapid response. I've put up a wiki page and will be
adding names as they come through
http://wiki.postg
I'm beginning to work on advanced additions to in-core replication for
PostgreSQL.
There are a number of additional features for existing single-master
replication still to achieve, but the key topics to be addressed are
major leaps forward in functionality. I hope to add useful features in
9.3, t
49 matches
Mail list logo
