Stephan Szabo said:
>
> On Thu, 31 Jul 2003, Christopher Browne wrote:
>
>> select * from log_table where request_time between 'june 11 2003'
>> and
>> 'june 12 2003';
>>
>> returns a plan:
>> Subquery Scan log_table (cost=0.00..10950.26 rows=177126 width=314)
>> -> Append (cost=0.00..10950.26 rows=177126 width=314)
>> -> Subquery Scan *SELECT* 1 (cost=0.00..3089.07 rows=50307
>> width=71)
>> -> Seq Scan on log_table_1 (cost=0.00..3089.07
>> rows=50307 width=71)
>> -> Subquery Scan *SELECT* 2 (cost=0.00..602.92 rows=9892
>> width=314)
>> -> Seq Scan on log_table_2 (cost=0.00..602.92
>> rows=9892 width=314)
>> -> Subquery Scan *SELECT* 3 (cost=0.00..2390.09 rows=39209
>> width=314)
>> -> Seq Scan on log_table_3 (cost=0.00..2390.09
>> rows=39209 width=314)
>
> What version are you using? In 7.3 and up it should be willing to
> consider moving the clause down, unless there's something like a type
> mismatch (because in that case it may not be equivalent without a bunch
> more work on the clause).
That was 7.2.4, although I had also tried it on 7.4 (yesterday's CVS).
Which provides four findings:
1. On 7.2.4, adding additional type info just doesn't help, fitting with
the notion that, consistent with your comment, improvement wouldn't happen
earlier than 7.3.
There's no help on 7.2 :-(, and the system I'm initially most interested
in using this on is still on 7.2.
2. When I retried on 7.4, it _did_ find search paths based on Index Scan,
when I added in additional type information. So the optimization I was
wishing for _is_ there :-). In the longer term, that's very good news.
3. I'll have to test this out on 7.3.4, now, as I hadn't, and it sounds
as though that is an interesting case.
4. It's often necessary to expressly specify type information in queries
to get the optimizer to do the Right Thing.
--
(reverse (concatenate 'string "ofni.smrytrebil@" "enworbbc"))
<http://dev6.int.libertyrms.info/>
Christopher Browne
(416) 646 3304 x124 (land)
