From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Hannu Krosing <hannu(at)krosing(dot)net>, Jim Nasby <jim(at)nasby(dot)net>, Christopher Browne <cbbrowne(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Future In-Core Replication |
Date: | 2012-05-04 13:16:22 |
Message-ID: | CA+U5nM+Bi7Z-7rzvPJxMZaXku3Tvrw08mEUJ94AdvVXaiQ7OTQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 4 May 2012 14:01, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Fri, May 4, 2012 at 8:32 AM, Hannu Krosing <hannu(at)krosing(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2012-05-04 13:17:28 | Re: Advisory locks seem rather broken |
Previous Message | Simon Riggs | 2012-05-04 13:11:52 | Re: CLOG extension |