| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Colin McGuigan <cmcguigan(at)earthcomber(dot)com> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Odd problem with planner choosing seq scan |
| Date: | 2007-04-22 02:45:11 |
| Message-ID: | 16596.1177209911@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Colin McGuigan <cmcguigan(at)earthcomber(dot)com> writes:
> I know I can do it by adjusting cost parameters, but I was really
> curious as to why adding a "LIMIT 5000" onto a SELECT from a table with
> only 530 rows in it would affect matters at all.
The LIMIT prevents the sub-select from being flattened into the main
query. In the current code this has a side-effect of preventing any
statistical information from being used to estimate the selectivity
of the filter conditions --- so you get a default rowcount estimate
that's way too small, and that changes the shape of the join plan.
It's giving you the "right" answer for entirely the wrong reason.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ulrich Cech | 2007-04-22 09:01:19 | Re: Large objetcs performance |
| Previous Message | Colin McGuigan | 2007-04-22 01:48:22 | Re: Odd problem with planner choosing seq scan |