| From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
|---|---|
| To: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
| Cc: | Karim Nassar <karim(dot)nassar(at)acm(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Delete query takes exorbitant amount of time |
| Date: | 2005-03-28 10:21:03 |
| Message-ID: | 1112005263.11750.886.camel@localhost.localdomain |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Sun, 2005-03-27 at 07:05 -0800, Stephan Szabo wrote:
> On Sat, 26 Mar 2005, Karim Nassar wrote:
> > Some improvement. Even better once it's cached. Row estimate didn't
> > change. Is this the best I can expect? Is there any other optimizations
> > I am missing?
>
> I'm not sure, really. Running a seq scan for each removed row in the
> referenced table doesn't seem like a particularly good plan in general
> though, especially if the average number of rows being referenced isn't
> on the order of 500k per value. I don't know what to look at next though.
>
Karim, please...
run the EXPLAIN after doing
SET enable_seqscan = off
Thanks,
Best Regards, Simon Riggs
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Steve Poe | 2005-03-28 12:11:59 | Re: which dual-CPU hardware/OS is fastest for PostgreSQL? |
| Previous Message | Stephan Szabo | 2005-03-27 15:05:38 | Re: Delete query takes exorbitant amount of time |