Re: WIP: Deferrable unique constraints

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Dean Rasheed <dean(dot)a(dot)rasheed(at)googlemail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, David Fetter <david(at)fetter(dot)org>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: WIP: Deferrable unique constraints
Date: 2009-07-27 23:04:38
Message-ID: 18152.1248735878@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Stark <gsstark(at)mit(dot)edu> writes:
> For foreign keys I was picturing some way to issue an SQL statement
> like "SELECT from tabletocheck where ctid in (<magic parameter>) and
> not exists (select 1 from referenced_table where pk =
> tabletocheck.fk)" and then somehow pass the list of ctids from the
> deferred list.

I have no problem with having some "magic" in there --- FK checks
already have to do some things that aren't expressible in standard SQL,
because of snapshotting issues. However, the above still presumes that
we can afford to store all the CTIDs involved. Which is more or less
exactly what the trigger event queue is doing now. We need a different
view about that bit, I think.

Perhaps we could remember the CTIDs the transaction has touched in a
bitmap (which could become lossy under memory pressure)? On a lossy
page you'd need to check all the tuples to see which ones have xmins
matching your transaction; but that's not too terrible and at least
you're not visiting pages you don't need to.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-07-27 23:12:31 Re: WIP: Deferrable unique constraints
Previous Message Greg Stark 2009-07-27 22:43:04 Re: WIP: Deferrable unique constraints