Re: Views With Unions - Mailing list pgsql-performance

From Christopher Browne
Subject Re: Views With Unions
Date
Msg-id 60vfthl6q6.fsf@dev6.int.libertyrms.info
Whole thread Raw
In response to Re: Views With Unions  (Stephan Szabo <sszabo@megazone.bigpanda.com>)
Responses Re: Views With Unions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
> On Fri, 1 Aug 2003, Christopher Browne wrote:
>> Stephan Szabo said:
>> > 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.
>
> If you really wanted you could try going back and finding the diffs
> associated with this in the CVS history or committers archives and see if
> you can make equivalent changes to 7.2, but that's possibly going to be
> difficult.

Somehow I don't think that'll fly; I have taken a brief look at some
of the optimizer code, and I very much don't want to leap into that at
the moment.  (I don't imagine I'd be able to muster much enthusiasm
for the idea from others that are involved, either.  More likely, I'm
understating the probable opposition to the idea...  :-))

I was hoping there would be some help on 7.2, but can live without it.
This approach to improving log purgeability is NOT the sort of thing
that you deploy on a day's notice because it seems like a "neat idea."
If it waits a couple months to be implemented, that's doubtless OK.

>> 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.

It turns out nicely on 7.3.4, using index scans for the subqueries in
the query:

   select count(*) from log_table where event_date between
         '2003-04-01' and '2003-05-01';

Which is a Good Thing.

>> 4.  It's often necessary to expressly specify type information in
>> queries to get the optimizer to do the Right Thing.
>
> Especially for cases like this. It takes the safer route of not
> pushing things down when it's not sure if pushing down might change
> the semantics (for example if a union piece has a different type
> from the union output, simply pushing clauses down unchanged could
> change the results)
>
> Tom would probably be willing to relax conditions if it could be
> proven safe even for the wierd outlying cases with char and varchar
> and such.

Evidently the dates of the form '2003-04-01' and such are getting
types promoted properly enough.  I don't see anything to "lobby" for
at this point.

The DOMAIN case I mentioned the other day had something odd going on
that LOST the type information associated with the domain.  Albeit
that was on 7.3, whereas the changes in DOMAIN functionality that make
them meaningfully useful come in 7.4...
--
let name="cbbrowne" and tld="libertyrms.info" in name ^ "@" ^ tld;;
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 646 3304 x124 (land)

pgsql-performance by date:

Previous
From: Stephan Szabo
Date:
Subject: Re: Views With Unions
Next
From: Francisco Reyes
Date:
Subject: How number of columns affects performance