Results 1 to 4 of 4
  1. #1
    Join Date
    Jan 2010
    Posts
    4

    Unanswered: OR clause gives us hell, while a UNION works very well

    As part of a large system, we have four tables - Company, Person, Order and Order_Person. The Order carries the ID of the Company it is for and uses a linking table between People and Orders called Order_People. I need a list of all orders for companies in my Territory or for people in my Territory (Territory is just number on Company and Person). So here's the simple SQL:

    select Company, Order_Date from Company, Person, Order, Order_Person where (
    (Order.Company = Company.Company_Id and Company.Territory =140)
    or
    (Order.Order_Id = Order_Person.Order_Id and Order_Person.Person_Id = Person.Person_Id and Person.Territory = 140)
    );
    This thing just runs and runs and runs. EXPLAIN gives me this terribly big number, primarily because its doing a sequential scan on the Company and Person tables.
    An equivalent query using a UNION, on the other hand, just *zips*:
    select Company, Order_Date from Company, Person, Order, Order_Person where (Order.Company = Company.Company_Id and Company.Territory =140)
    UNION
    select Company, Order_Date from Company, Person, Order, Order_Person where (Order.Order_Id = Order_Person.Order_Id and Order_Person.Person_Id = Person.Person_Id and Person.Territory = 140);
    The problem is, this is part of a large app that does a lot of these kinds of OR-based queries. They all run fine against the earlier db we used (DB2). Migrating to Postgres, though, all these OR queries bring the system to its knees. So here's my question: Is there a way to make the OR-based queries work OK in Postgres? Or is recoding everything my our option?

  2. #2
    Join Date
    Nov 2003
    Posts
    2,935
    Provided Answers: 12
    Quote Originally Posted by nmandyam View Post
    Is there a way to make the OR-based queries work OK in Postgres? Or is recoding everything my our option?
    We need more information
    - show us the DDL for the tables including any indexes that are defined.
    - show us the explain output (ideally upload them to explain.depesz.com and post the link. Then the post won't be cluttered with a large explain output)

  3. #3
    Join Date
    Jan 2010
    Posts
    4

    Relevant DDL, etc.

    Here's the relevant DDL (shortened for readability/applicability etc.). I couldn't figure out the use of depesz..., so I've attached a text file that contains the two EXPLAINS.
    -------------------------------
    create table company (
    company_id decimal (10) not null ,
    company_name varchar (100) not null,
    territory decimal (10) not null,
    constraint company__pk primary key (company_id)
    );

    create table person (
    person_id decimal (10) not null,
    first_name varchar (50) not null,
    last_name varchar (50),
    department varchar (500),
    territory decimal (10) not null,
    constraint person__pk primary key (person_id)
    );

    create table order (
    order_id decimal (10) not null,
    company decimal (10) not null,
    ord_date timestamptz not null,
    sales_person decimal (10),
    shipping_charges decimal (10,3),
    constraint order__pk primary key (order_id)
    );

    create table order_person (
    order_person_id decimal (10) not null,
    order_id decimal (10) not null,
    person_id decimal (10) not null,
    order_person_type_id decimal (10) not null,
    constraint order_person__pk primary key (order_person_id)
    );

    alter table company add constraint ix_1_company_territory foreign key (territory) references territory (territory_id) on delete cascade;
    alter table person add constraint ix_82_person_territory foreign key (territory) references territory (territory_id) on delete cascade;
    alter table order add constraint ix_247_order_company foreign key (company) references company (company_id) on delete cascade;
    alter table order_person add constraint fk__order_person_order_id foreign key (order_id) references order (order_id) on delete cascade;
    alter table order_person add constraint ix_241_order_person_person_id foreign key (person_id) references person (person_id) on delete cascade;
    ----------------------
    Attached Files Attached Files

  4. #4
    Join Date
    Nov 2003
    Posts
    2,935
    Provided Answers: 12
    The statements look very strange. Is this intended that you do not correctly join the tables involved? Especiall in the "first" part of the query you are basically doing a cross join between Person, Order and Order_Person because you are completely missing join conditions on those tables.

    My assumption is, that due to the implicit DISTINCT that UNION does, Postgres sees that it can use a different access path. From the table definition I would say the indexes are sufficient.

    I would revisit the join conditions to get rid of the cross joins e.g. by writing explicit JOIN conditions.

    I couldn't figure out the use of depesz
    Simply paste the execution plan into the big empy white space

    After hitting submit, you can post the generated URL:
    http://explain.depesz.com/s/OUT
    http://explain.depesz.com/s/od

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •