From: | Mike Mascari <mascarm(at)mascari(dot)com> |
---|---|
To: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
Cc: | Don Baccus <dhogaza(at)pacifier(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Proposal: TRUNCATE TABLE table RESTRICT |
Date: | 2000-06-12 23:48:59 |
Message-ID: | 394576EB.3254904B@mascari.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jan Wieck wrote:
>
> Mike Mascari wrote:
> > Sorry to ask for another favor, but what does Oracle do here? If
> > a referring table has 1,000,000 rows in it which have been
> > deleted but not vacuumed, what would the performance implications
> > be?
>
> Referential integrity has no performance impact on VACUUM. If
> that's what you aren't sure about.
>
> Jan
Actually, I was worried that if TRUNCATE were to vist all
referring tables to determine whether or not it was empty, rather
then just issuing an elog() at the first RI trigger encountered,
that it might wind up scanning a 1,000,000 tuple relation (the
referring relation) where all the rows have been marked as
deleted before determining that its okay to perform the TRUNCATE.
I was hoping that Oracle simply disallowed TRUNCATE on tables
with referring relations, regardless of whether or not there was
actually any data in them, so that PostgreSQL could do the same.
:-)
Mike Mascari
From | Date | Subject | |
---|---|---|---|
Next Message | Don Baccus | 2000-06-12 23:51:20 | Re: Proposal: TRUNCATE TABLE table RESTRICT |
Previous Message | Lamar Owen | 2000-06-12 23:36:29 | PostgreSQL 7.0.2-2 RPMset available. |