| From: | Matthew Wakeling <matthew(at)flymine(dot)org> |
|---|---|
| To: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Very specialised query |
| Date: | 2009-03-30 10:24:32 |
| Message-ID: | alpine.DEB.2.00.0903301119120.21772@aragorn.flymine.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Fri, 27 Mar 2009, Tom Lane wrote:
>> Notice the two different index conditions:
>> (l1.end > l2.start) AND (l1.start < l2.start) - "between"
>> (l1.end > l2.start) AND (l1.start >= l2.start) - open-ended
>> Both have a cost of (cost=0.00..123.10 rows=4809 width=12)
> Currently the planner only notices that for a range check that involves
> comparisons of the same variable expression to two constants (or
> pseudoconstants anyway). In principle it might be reasonable to have a
> heuristic that reduces the estimated selectivity in the example above,
> but it looks to me like it'd make clauselist_selectivity() a lot slower
> and more complicated. When you see (l1.end > l2.start), how do you know
> which variable to try to match up against others? And if you try to
> match both, what do you do when you get matches for both?
Those two index conditions are on an index scan on the field l2.start.
Therefore, I would expect to only have to take any notice of l2.start when
working out selectivity on a range check for this particular plan. When
there is an index scan on a different field, then try and match that one
up instead.
Matthew
--
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Matthew Wakeling | 2009-03-30 10:26:03 | Re: Very specialised query |
| Previous Message | Matthew Wakeling | 2009-03-30 10:17:48 | Re: Very specialised query |