From: | t-ishii(at)sra(dot)co(dot)jp |
---|---|
To: | hackers(at)postgreSQL(dot)org |
Cc: | t-ishii(at)srapc451(dot)sra(dot)co(dot)jp |
Subject: | subselect and optimizer |
Date: | 1998-04-10 02:14:32 |
Message-ID: | 199804100214.LAA13959@srapc451.sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
This question was sent to me by a user who uses PostgreSQL 6.3.1.
Is this normal?
(Note that the patch for src/backend/optimizer/path/prune.c created by
Vadim did not help)
--
Tatsuo Ishii
t-ishii(at)sra(dot)co(dot)jp
------------------------------------------------------------------
The following query seems to generate a rather slow query plan.
explain select * from product,order_tbl where
product.serial=order_tbl.serial and product.serial in (select serial
from order_tbl where cust_id='ABCDE');
NOTICE: QUERY PLAN:
Hash Join (cost=906.09 size=744 width=110)
-> Seq Scan on order_tbl (cost=296.13 size=6822 width=36)
-> Hash (cost=0.00 size=0 width=0)
-> Seq Scan on product (cost=358.29 size=744 width=74)
SubPlan
-> Index Scan on order_tbl (cost=2.05 size=1 width=12)
EXPLAIN
product and order_tbl are defined as follows:
create table product (
serial char(10) primary key,
pname char(15) not null,
price int2);
create index prod_name on product using hash(pname);
create table order_tbl (
cust_id char(5) primary key,
serial char(10) not null,
nums int2,
o_date date);
create index order_ser on order_tbl using hash(serial);
* product has 7289 tuples, and order_tbl has 6818 tuples.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1998-04-10 02:40:28 | Re: [HACKERS] Re: Release notes |
Previous Message | Bruce Momjian | 1998-04-10 02:10:34 | Re: [HACKERS] New pg_type for large object |