Re: View prevents index

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
Cc: chris+pg-general(at)netmonger(dot)net, pgsql-general(at)postgresql(dot)org
Subject: Re: View prevents index
Date: 2001-07-12 14:07:36
Message-ID: 16962.994946856@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> writes:
>> It's not immediately obvious to me that these are equivalent, or
>> perhaps I should say it's not clear under what conditions is the
>> transformation legitimate.

> Could you tell me in what cases two of above are not equivalent?

It may well be OK, I just want to see a rigorous demonstration of it.
It *looks* right, but intuition is frequently misleading. Two points
that particularly need thought are (a) what about NULLs --- SQL's
three-way boolean logic breaks a lot of other things that seem right
intuitively; (b) does the same equivalence hold for UNION ALL,
INTERSECT, INTERSECT ALL, EXCEPT, EXCEPT ALL?

If you think that it's so obvious as not to require any thought,
I offer the following counterexample:

... WHERE random() > 0.5;

Pushing down a WHERE like this one *will* change the results.

That particular case doesn't bother me, but user-defined functions
that access other tables might have history-dependent behavior,
too. Do we need to allow for that?

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message wsheldah 2001-07-12 14:10:49 Re: Re: Pg7.2 (was: vacuum and 24/7 uptime)
Previous Message Bruno Wolff III 2001-07-12 13:24:31 Re: Pg7.2 (was: vacuum and 24/7 uptime)