I guess it depends on the optimiser and how clever it is. With the
former the db will probably generate 2 sets of ids for the 2 joined
tables (a, b) which only contain the values you require, these lists are
probably much smaller than the total number of rows in the table
therefore any merges a
I have a "master-detail" kind of situation, as illustrated here:
CREATE TABLE master(
id SERIAL PRIMARY KEY,
foo TEXT
);
CREATE TABLE detail(
id SERIAL PRIMARY KEY
master BIGINT NOT NULL REFERENCES master(id),
bar TEXT
);
(this is a simplification, of cou
On Mon, Dec 8, 2008 at 1:56 PM, Christopher Maier <[EMAIL PROTECTED]> wrote:
> I have a "master-detail" kind of situation, as illustrated here:
>
> CREATE TABLE master(
>id SERIAL PRIMARY KEY,
>foo TEXT
> );
>
> CREATE TABLE detail(
>id SERIAL PRIMARY KEY
>master BIG
On Mon, Dec 8, 2008 at 2:28 PM, Scott Marlowe <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 8, 2008 at 1:56 PM, Christopher Maier <[EMAIL PROTECTED]> wrote:
>> I have a "master-detail" kind of situation, as illustrated here:
>>
>> CREATE TABLE master(
>>id SERIAL PRIMARY KEY,
>>foo TEXT
On Mon, Dec 8, 2008 at 1:28 PM, Scott Marlowe <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 8, 2008 at 1:56 PM, Christopher Maier <[EMAIL PROTECTED]> wrote:
>> I have a "master-detail" kind of situation, as illustrated here:
>>
>> CREATE TABLE master(
>>id SERIAL PRIMARY KEY,
>>foo TEXT
On Mon, Dec 8, 2008 at 2:31 PM, Richard Broersma
<[EMAIL PROTECTED]> wrote:
> One Idea that popped into my head that may-or-may-not work would be to
> add a constraint trigger that checks if all of the detail records have
> the same xmin as the order table record.
Yes, it's not as simple as I firs
