Re: Future In-Core Replication - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Future In-Core Replication
Date
Msg-id CA+U5nM+Bi7Z-7rzvPJxMZaXku3Tvrw08mEUJ94AdvVXaiQ7OTQ@mail.gmail.com
Whole thread Raw
In response to Re: Future In-Core Replication  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 4 May 2012 14:01, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, May 4, 2012 at 8:32 AM, Hannu Krosing <hannu@krosing.net> 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 just one matching row.
>>
>> IIRC updating (or deleting) CURRENT OF a cursor is currently supported
>> only in pl/pgsql so this needs to be done using a plpgsql cursor.
>>
>> If the table has no indexes or index lookup returns lots of rows, then
>> this is bound to be slow, but in this case it was probably slow on
>> master too :)
>
> I was about to write a reply saying exactly this, but you said it
> better than I would have been able to manage.
>
> I think this is all exactly right.

Yes, but its not a high priority for inclusion. Many things like this
will need to wait behind the really critical additional features.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: CLOG extension
Next
From: Robert Haas
Date:
Subject: Re: Advisory locks seem rather broken