From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephan Szabo <sszabo@megazone23.bigpanda.com>
Cc: Tomasz Myrta <jasiek@klaster.net>
Cc: pgsql-sql@postgresql.org
Subject: Re: To use a VIEW or not to use a View.....
Date: Thu, 23 Jan 2003 14:54:09 -0500
Message-ID: <27669.1043351649@sss.pgh.pa.us> (raw)
In-Reply-To: <20030123095104.I13544-100000@megazone23.bigpanda.com>
References: <20030123095104.I13544-100000@megazone23.bigpanda.com>
Stephan Szabo <sszabo@megazone23.bigpanda.com> writes:
> On Thu, 23 Jan 2003, Tom Lane wrote:
>> What I was thinking was that any time the code sees a "var = const"
>> clause as part of a mergejoin equivalence set, we could mark all the
>> "var = var" clauses in the same set as no-ops. For example, given
>> WHERE a.f1 = b.f2 AND b.f2 = c.f3 AND c.f3 = 42
>> then after we finish deducing a.f1 = 42 and b.f2 = 42, there is no
>> longer any value in either of the original clauses a.f1 = b.f2 and
>> b.f2 = c.f3, nor in the other deduced clause a.f1 = c.f3. This would
>> take a little bit of restructuring of generate_implied_equalities() and
>> process_implied_equality(), but it doesn't seem too difficult to do.
>>
>> Thoughts? Are there any holes in that logic?
> The main thing I can think of is being careful when the types are
> different (like padding vs no padding in strings).
This is a matter of being careful about marking cross-datatype operators
as mergejoinable. We do not mark 'bpchar = text' as mergejoinable ---
in fact we don't even have such an operator. AFAICS any pitfalls in
those semantics come up already from the existing logic to treat
mergejoinable equality as transitive for variables. Extending that
transitivity to constants can't create problems that wouldn't exist
anyway.
For reference, these are the only cross-datatype mergejoinable operators
as of CVS tip:
regression=# select oid::regoperator,oprcode from pg_operator where oprlsortop!=0 and oprleft!=oprright;
oid | oprcode
--------------------------+-----------
=(integer,bigint) | int48eq
=(bigint,integer) | int84eq
=(smallint,integer) | int24eq
=(integer,smallint) | int42eq
=(real,double precision) | float48eq
=(double precision,real) | float84eq
=(smallint,bigint) | int28eq
=(bigint,smallint) | int82eq
(8 rows)
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: tgl@sss.pgh.pa.us, sszabo@megazone23.bigpanda.com, jasiek@klaster.net
Subject: Re: To use a VIEW or not to use a View.....
In-Reply-To: <27669.1043351649@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox