>Jeff Boes writes
> # explain select link_id from links l join clm_tmp_links t on
> (fn_urlrev(l.path_base) = t.rev_path_base);
> executes in 59.8 seconds!
> Now the odd part: if I change the query to this:
>
> # explain analyze select link_id from links l join clm_tmp_links t on
> (fn_urlrev(l
Jeff Boes <[EMAIL PROTECTED]> writes:
> Is this a bug in the optimizer? Or did something
> change about the way functional indexes are used?
In 7.3, the only possible plan for these queries was a nestloop or
nestloop with inner indexscan, because the planner could not generate
merge or hash joins
We have a large (several million row) table with a field containing
URLs. Now, funny thing about URLs: they mostly start with a common
substring ("http://www.";). But not all the rows start with this, so we
can't just lop off the first N characters. However, we noticed some time
ago that an ind
