It's a bit more complicated than that as there are also locking issues,
like what if other processes insert rows while some others are being
deleted, really the whole thing isn't trivial.
Since postgres already incoporates code to check foreign keys more
efficiently (when doing alter table .
On Tue, 25 Jan 2005, Florian G. Pflug wrote:
> Stephan Szabo wrote:
>
> > It's not sufficient to do the delete for non existant pk rows in the
> > deferred case. I also think we'd need to decide on the behavior for the
> > PostgreSQL case where a user trigger runs in between the delete and the
>
Stephan Szabo wrote:
The second is that
these triggers will want to know which rows are deleted, but AFAIK
statement-level triggers don't currently give you that information and
deleting/changing any rows that aren't satisfied does not give the correct
behavior.
This I do not understand. Isn't it s
Harald Fuchs <[EMAIL PROTECTED]> writes:
> "Florian G. Pflug" <[EMAIL PROTECTED]> writes:
>>> PostgreSQL doesn't automatically add indexes to foreign-key
>>> columns. That sounds like the issue to me.
>> Oh... *feeling a bit stupid*... Seems that I got confused, because it
>> requires an index to
In article <[EMAIL PROTECTED]>,
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
>> PostgreSQL doesn't automatically add indexes to foreign-key
>> columns. That sounds like the issue to me.
> Oh... *feeling a bit stupid*... Seems that I got confused, because it
> requires an index to exist on the r
On Mon, 24 Jan 2005, Florian G. Pflug wrote:
> Stephan Szabo wrote:
> > On Mon, 24 Jan 2005, Florian G. Pflug wrote:
> >
> >>Since postgres already incoporates code to check foreign keys more
> >>efficiently (when doing alter table ... add constraint .. foreign key,
> >>postgres seems to use a me
Stephan Szabo wrote:
On Mon, 24 Jan 2005, Florian G. Pflug wrote:
Since postgres already incoporates code to check foreign keys more
efficiently (when doing alter table ... add constraint .. foreign key,
postgres seems to use a merge or a hash join, instead of a nested loop),
I wondered how hard it
On Mon, 24 Jan 2005, Florian G. Pflug wrote:
> Since postgres already incoporates code to check foreign keys more
> efficiently (when doing alter table ... add constraint .. foreign key,
> postgres seems to use a merge or a hash join, instead of a nested loop),
> I wondered how hard it would be t
Richard Huxton wrote:
Florian G. Pflug wrote:
I ran into some performance problems regarding foreign keys lately.
My schema has about 20 tables, which each contain from 10 to 100.000
records. They have quite complicated interdependencies, modeled using
foregin keys set to "on update cascade, on de
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> when deleting a lot of rows from a large table - and each time it has to find
> referencing tuples by doing an index scan
Are you sure it was even an index scan? And not doing a sequential table scan
for every deletion? In order to do an index sca
Florian G. Pflug wrote:
Hi
I ran into some performance problems regarding foreign keys lately.
My schema has about 20 tables, which each contain from 10 to 100.000
records. They have quite complicated interdependencies, modeled using
foregin keys set to "on update cascade, on delete cascade".
The
Hi
I ran into some performance problems regarding foreign keys lately.
My schema has about 20 tables, which each contain from 10 to 100.000
records. They have quite complicated interdependencies, modeled using
foregin keys set to "on update cascade, on delete cascade".
The schema stores data for m
12 matches
Mail list logo
