On Tue, Sep 13, 2011 at 9:27 AM, Alvaro Herrera
wrote:
>> I wonder if it's a mistake to be thinking about solving this problem
>> by extending the MultiXact mechanism. Pushing xmax out-of-line so
>> that we have room to store tuple information seems expensive,
>> especially because there's no con
Excerpts from Robert Haas's message of mar sep 13 11:02:51 -0300 2011:
>
> On Fri, Sep 9, 2011 at 5:31 PM, Alvaro Herrera
> wrote:
> > [ multixact complexity ]
>
> I wonder if it's a mistake to be thinking about solving this problem
> by extending the MultiXact mechanism. Pushing xmax out-of-l
On Fri, Sep 9, 2011 at 5:31 PM, Alvaro Herrera
wrote:
> [ multixact complexity ]
I wonder if it's a mistake to be thinking about solving this problem
by extending the MultiXact mechanism. Pushing xmax out-of-line so
that we have room to store tuple information seems expensive,
especially because
Anyone on all of this?
On 09/09/2011 02:31 PM, Alvaro Herrera wrote:
Excerpts from Alvaro Herrera's message of mar ago 09 13:01:04 -0400 2011:
To implement this, we need to augment MultiXact to store the lock type
that each comprising Xid holds on the tuple. Two bits per Xid are
needed.
Excerpts from Alvaro Herrera's message of mar ago 09 13:01:04 -0400 2011:
> To implement this, we need to augment MultiXact to store the lock type
> that each comprising Xid holds on the tuple. Two bits per Xid are
> needed. My thinking is that we could simply extend the "members" to add
> a by
On Aug10, 2011, at 08:45 , Noah Misch wrote:
> On Tue, Aug 09, 2011 at 09:41:00PM +0200, Florian Pflug wrote:
>> Couldn't we simply give the user a way to specify, per column, whether or
>> not that column is a "KEY" column? Creating a foreign key constraint could
>> still implicitly mark all refer
On Aug9, 2011, at 22:40 , Tom Lane wrote:
> Alvaro Herrera writes:
>> Excerpts from Jeff Davis's message of mar ago 09 14:41:14 -0400 2011:
>>> Right now, FKs aren't really very special, they are mostly just
>>> syntactic sugar (right?). This proposal would make FKs special internal
>>> mechanisms
On Tue, Aug 09, 2011 at 01:01:04PM -0400, Alvaro Herrera wrote:
> KEY UPDATEFOR UPDATE FOR SHARE KEY SHARE
> KEY UPDATE X XX X
> FOR UPDATE X XX
> FOR SHAREX X
> KEY SHAREX
>
> DE
On Tue, Aug 09, 2011 at 09:41:00PM +0200, Florian Pflug wrote:
> Couldn't we simply give the user a way to specify, per column, whether or
> not that column is a "KEY" column? Creating a foreign key constraint could
> still implicitly mark all referenced columns as KEY columns, but columns
> would
On Aug 9, 2011, at 4:40 PM, Tom Lane wrote:
> Like Florian, I'm considerably more concerned about the aspect of
> deciding which columns are "key columns" and whether they changed.
Should we consider trying implement a system that can lock individual columns?
Either way, my main concern is that
Excerpts from Tom Lane's message of mar ago 09 16:40:15 -0400 2011:
> Alvaro Herrera writes:
> > Excerpts from Jeff Davis's message of mar ago 09 14:41:14 -0400 2011:
> >> Right now, FKs aren't really very special, they are mostly just
> >> syntactic sugar (right?). This proposal would make FKs sp
Alvaro Herrera writes:
> Excerpts from Jeff Davis's message of mar ago 09 14:41:14 -0400 2011:
>> Right now, FKs aren't really very special, they are mostly just
>> syntactic sugar (right?). This proposal would make FKs special internal
>> mechanisms, and I don't see the benefit in doing so.
> We
Excerpts from Florian Pflug's message of mar ago 09 15:41:00 -0400 2011:
> First, I'd like to see us support FKs which reference non-unqiue columns.
> As long as we restrict such FK constraints to ON UPDATE/DELETE RESTRICT
> (or NO ACTION), there's no conceptual difficulty in doing that. Yeah, I
>
On Aug9, 2011, at 19:01 , Alvaro Herrera wrote:
> Note that this means that UPDATE would always have to check whether key
> columns are being modified. (I loosely talk about "key columns" here
> referring to columns involving unique indexes. On tables with no unique
> indexes, I think this would
On Aug9, 2011, at 19:01 , Alvaro Herrera wrote:
> This would also help us find a solution to the problem that an aborted
> subtransaction that updates or excl-locks a tuple causes an earlier
> shared lock to be forgotten. We would deal with this by marking the
> Xmax with a new MultiXact that incl
Excerpts from Jeff Davis's message of mar ago 09 14:41:14 -0400 2011:
> On Tue, 2011-08-09 at 13:01 -0400, Alvaro Herrera wrote:
> > Note that the KEY UPDATE lock would be an internal option, not exposed
> > to SQL. I think we already have enough extensions in this area. We are
> > forced to expo
On Tue, 2011-08-09 at 13:01 -0400, Alvaro Herrera wrote:
> Note that the KEY UPDATE lock would be an internal option, not exposed
> to SQL. I think we already have enough extensions in this area. We are
> forced to expose KEY SHARE because RI triggers get to it via SPI, but I
> would be happy to
Hi,
Previously, we had some discussion to introduce a new type of tuple lock
to let foreign keys be lighter weight, allowing for more concurrency.
During the course of that discussion, it became evident that the
solution being proposed didn't go all the way to solve the problem. A
proposal by Noa
18 matches
Mail list logo
