On Fri, 2003-06-20 at 13:06, Yusuf wrote:
> [EMAIL PROTECTED] wrote:
> > On Fri, 2003-06-20 at 15:53, Yusuf wrote:
> >
> >>Why would the following query take soo long to run? What does 28.12 msec
> >>represent, since the total running time is
> >>16801.86 ms.
> >
> >
> > I'd hazard to guess th
[EMAIL PROTECTED] wrote:
On Fri, 2003-06-20 at 15:53, Yusuf wrote:
Why would the following query take soo long to run? What does 28.12 msec represent, since the total running time is
16801.86 ms.
I'd hazard to guess that you have a whole slew of foreign keys cascading
to delete, update, or ch
Rod Taylor <[EMAIL PROTECTED]> writes:
> On Fri, 2003-06-20 at 15:53, Yusuf wrote:
>> Why would the following query take soo long to run? What does 28.12 msec =
> represent, since the total running time is=20
>> 16801.86 ms.
> I'd hazard to guess that you have a whole slew of foreign keys cascadin
On Fri, 2003-06-20 at 15:53, Yusuf wrote:
> Why would the following query take soo long to run? What does 28.12 msec represent,
> since the total running time is
> 16801.86 ms.
I'd hazard to guess that you have a whole slew of foreign keys cascading
to delete, update, or check many rows from oth
Why would the following query take soo long to run? What does 28.12 msec represent, since the total running time is
16801.86 ms.
The table phoneinfo has a primary key called phoneinfo_id and the table has 400 000 records.
mydb=#explain analyze delete from phoneinfo where phoneinfo_id = 85723;
