Thanks to everyone for the responses ... ended up doing a trigger on the
comments table that updates another table to maintain a "pointer" to the
active record ... sped up the query that was hampering us from ~26 000ms
to 47ms ... the killer part of the query was that each time it was havin
g
On Thursday 05 January 2006 04:58, [EMAIL PROTECTED] wrote:
>That's not what foreign keys do. The only thing a foreign key
> provides is a guarantee that if any records in B (the referencing
> table) still reference a record in table A (the referenced table)
> then you cannot delete that reference
> Now, what I want to do is add a FOREIGN KEY (again, I think) that when
> incident_summary.status is changed (either closed, or reopened), the
> associated records in incident_comments are changed to the same state ...
As the other responders mentioned, from the schema you described, it
doesn't l
Marc
Is the "assumption" that anytime there are comments the status
changes?
If I'm reading between the lines correctly, there could be a large
number of comments before the status changes. So no need to change
status until explicitly needed.
If there is a specific "comment" th
On Wed, 4 Jan 2006, Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
Now, what I want to do is add a FOREIGN KEY (again, I think) that when
incident_summary.status is changed (either closed, or reopened), the
associated records in incident_comments are changed to the same state ..
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> Now, what I want to do is add a FOREIGN KEY (again, I think) that when
> incident_summary.status is changed (either closed, or reopened), the
> associated records in incident_comments are changed to the same state ...
Why not just get rid of the s
I'm not sure if I'm looking at (for) the right thing or not, but if I am,
then I'm not finding any useful examples :(
I have two tables, simplified as:
CREATE TABLE incident_summary (
id serial,
subject text,
status boolean
);
CREATE TABLE incident_comments (
id serial,
incident_id
