| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Cc: | Karim A Nassar <Karim(dot)Nassar(at)NAU(dot)EDU>, Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>, 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-29 14:40:57 |
| Message-ID: | 21461.1112107257@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> ...but, I see no way for OidFunctionCall8 to ever return an answer of
> "always just 1 row, no matter how big the relation"...so tuples_fetched
> is always proportional to the size of the relation. Are unique indexes
> treated just as very-low-selectivity indexes?
Yeah. It is not the job of amcostestimate to estimate the number of
rows, only the index access cost. (IIRC there is someplace in the
planner that explicitly considers unique indexes as a part of developing
selectivity estimates ... but it's not that part.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Cott Lang | 2005-03-29 14:52:54 | Re: How to improve db performance with $7K? |
| Previous Message | Tom Lane | 2005-03-29 14:29:20 | Re: Delete query takes exorbitant amount of time |