From: | Noah Misch <noah(at)2ndQuadrant(dot)com> |
---|---|
To: | Florian Pflug <fgp(at)phlo(dot)org> |
Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: augmenting MultiXacts to improve foreign keys |
Date: | 2011-08-10 06:45:37 |
Message-ID: | 20110810064534.GA15182@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 no longer be "KEY" columns simply because they're part of a UNIQUE
> constraint. Users would be free to add arbitrary columns to the set of
> "KEY" columns by doing ALTER TABLE ALTER COLUMN SET KEY.
What would be the use case for manually expanding the set of key columns?
If you have a heavily-updated table referenced by slowly-changing tables, it
might pay off to disable the optimization entirely. That would be an esoteric
escape hatch to provide for an uncommon use case, though.
--
Noah Misch http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | pasman pasmański | 2011-08-10 06:53:42 | Re: Problem with sources. |
Previous Message | Peter van Hardenberg | 2011-08-10 01:00:42 | Re: Policy on pulling in code from other projects? |