| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jack Orenstein <jack(dot)orenstein(at)hds(dot)com> |
| Cc: | Sam Mason <sam(at)samason(dot)me(dot)uk>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Slight change in query leads to unexpected change in query plan |
| Date: | 2009-06-23 14:11:56 |
| Message-ID: | 13786.1245766316@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Jack Orenstein <jack(dot)orenstein(at)hds(dot)com> writes:
> Limit (cost=0.00..324.99 rows=100 width=451)
> -> Index Scan using t_pkey on t (cost=0.00..296027.98 rows=91088 width=451)
> Index Cond: (pk > 1000000000)
> Adding the value restriction at the top of this query plan wouldn't increase the
> cost very much.
You're missing the point: with the value restriction in place, it's
estimating that it will probably have to scan all 91000 rows (because
there are fewer than 100 satisfying the value restriction). And that
is going to cost somewhere north of 296027 cost units --- the cost
shown, plus 91000 invocations of the value-restriction check.
Which is considerably more than the cost of the other plan.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Fetter | 2009-06-23 14:12:53 | Re: [BUGS] Integrity check |
| Previous Message | Tom Lane | 2009-06-23 14:04:32 | Re: Explaining functions. |