Hi, If the join is to a primary key or notnull unique column(s), then inner join is also ok. But of course left join is the simpler case. An example: create table person (id serial primary key, name varchar not null); create table pet (id serial primary key, name varchar not null, person_id int not null references person(id)); create view v_pet_person as select pet.id as pet_id, pet.name as pet_name, person_id as person_id, person.name as person_name from pet join person (pet.person_id=person.id); At this point we know that optimization may be possible because of the primary key on person. The optimization depends on the primary key constraint. Kindof internal dependency. We can find out that which "from-element" is a given field's source as far they are simple references. This can be stored. Then query the view: select pet_name, person_id from v_pet_person where person_id=2; In this case we don't need the join. These queries are usually dynamically generated, the selection list and the where condition is the dynamic part. Best Regards, Otto 2006/1/12, Scott Marlowe <smarlowe@xxxxxxxxxxxxxxxxx>: > On Thu, 2006-01-12 at 11:00, Ottó Havasvölgyi wrote: > > Hi, > > > > I think it would be sufficient only for views. In other cases the > > programmer can optimize himself. But a view can be a join of other > > tables, and it is not sure that all of them are always needed. It all > > depends on what I select from the view. > > The idea that you could throw away joins only works for outer joins. > I.e. if you did: > > select a.x, a.y, a.z from a left join b (on a.id=b.aid) > > then you could throw away the join to b. But if it was a regular inner > join then you couldn't know whether or not you needed to join to b > without actually joining to b... >
