| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bruno Wolff III <bruno(at)wolff(dot)to> |
| Cc: | "Craig A(dot) James" <cjames(at)modgraph-usa(dot)com>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Optimizer: limit not taken into account |
| Date: | 2006-05-17 18:30:22 |
| Message-ID: | 24245.1147890622@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Bruno Wolff III <bruno(at)wolff(dot)to> writes:
> I suspect it wasn't intended to be a full table scan. But rather a sequential
> scan until it found a matching row. If the data in the table is ordered by
> by id, this strategy may not work out well. Where as if the data is randomly
> ordered, it would be expected to find a match quickly.
Right. You can see from the differential in the estimates for the
SeqScan and the Limit nodes that the planner is not expecting the
seqscan to run to completion, but rather to find a matching row quite
quickly.
There is not anything in there that considers whether the table's
physical order is so nonrandom that the search will take much longer
than it would given uniform distribution. It might be possible to do
something with the correlation statistic in simple cases ...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Craig A. James | 2006-05-17 18:58:09 | Re: Optimizer: limit not taken into account |
| Previous Message | Simon Riggs | 2006-05-17 18:22:09 | Re: Optimizer: limit not taken into account |