Re: Why this Query Plan is different

Hi Tom,

Begging your pardon for mislabeling the query plan output, please find the
correctly labeled output.

**** This is Box A which runs on 7.4.5 and delivers very quick result.

production=# SELECT version();
version

----------------------------------------------------------------------------
-----------------------------------------------------
PostgreSQL 7.4.5 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.3.4
20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)
(1 row)

production=# EXPLAIN ANALYSE SELECT count(airport_code) FROM properties
WHERE airport_code::character varying IN (SELECT airport_code::character
varying FROM airport_codes);
QUERY PLAN

----------------------------------------------------------------------------
------------------------------------------------------
Aggregate (cost=7494.95..7494.95 rows=1 width=4) (actual
time=285.821..285.823 rows=1 loops=1)
-> Hash IN Join (cost=228.67..7393.46 rows=40593 width=4) (actual
time=24.994..279.818 rows=5833 loops=1)
Hash Cond: (("outer".airport_code)::text =
(("inner".airport_code)::character varying)::text)
-> Seq Scan on properties (cost=0.00..2156.93 rows=40593 width=4)
(actual time=0.035..83.152 rows=40593 loops=1)
-> Hash (cost=179.54..179.54 rows=7654 width=7) (actual
time=24.491..24.491 rows=0 loops=1)
-> Seq Scan on airport_codes (cost=0.00..179.54 rows=7654
width=7) (actual time=0.046..12.481 rows=7654 loops=1)
Total runtime: 286.234 ms
(7 rows)

****** And this is the Box B which runs on 7.3.9 and takes hours to deliver
the result. Actually I didn't execute EXPLAIN ANALYSE on Box B, because when
I tried, it went for more than 20-30 Minutes.

production=> SELECT version();
version

----------------------------------------------------------------------------
-----------------------------------------------------------------
PostgreSQL 7.3.9 on i686-pc-linux-gnu, compiled by GCC
i686-pc-linux-gnu-gcc (GCC) 3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3,
pie-8.7.7.1)
(1 row)

production=> EXPLAIN SELECT count(airport_code) FROM properties WHERE
airport_code::character varying IN (SELECT airport_code::character varying
FROM airport_codes);
QUERY PLAN
----------------------------------------------------------------------------
----
Aggregate (cost=3605245.81..3605245.81 rows=1 width=4)
-> Seq Scan on properties (cost=0.00..3605195.64 rows=20068 width=4)
Filter: (subplan)
SubPlan
-> Seq Scan on airport_codes (cost=0.00..179.54 rows=7654
width=7)
(5 rows)

Regards,

Thilina

-----Original Message-----
From: pgsql-admin-owner(at)postgresql(dot)org
[mailto:pgsql-admin-owner(at)postgresql(dot)org] On Behalf Of Tom Lane
Sent: 24 March 2005 11:59
To: tgunasekara(at)openworld(dot)org
Cc: PGSQL Admin
Subject: Re: [ADMIN] Why this Query Plan is different

"Thilina Gunasekara" <tgunasekara(at)openworld(dot)org> writes:
> I have two PostgreSQL Database Servers running on Gentoo which versions
are
> PostgreSQL 7.4.5 (Box A) and PostgreSQL 7.3.9 (Box B)
> Due to a recent query posted by a developer I was interested to know which
> factors are affecting these two servers to behave in a different manner to
> the same query. Please shed light on this.

7.4 knows a great deal more about optimizing IN queries than 7.3 does.
I think you have misidentified the two query plans, because "Hash IN
Join" is not a plan type that 7.3 has at all. What is not clear to me
is which version is really slower. Could we see EXPLAIN ANALYZE output
(correctly labeled ;-)) not just EXPLAIN?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings