Обсуждение: indexing issues: what's the fasted join method?
I'm running PostgreSQL 6.4 on Linux, and have the following database setup:
i have 2 tables, table1 and table2, both with an 'id' field, and both with
an index on the 'id' field.
Usually my selects involve a join between the tables, but the join is quite
slow. I played around with the EXPLAIN command, and got the following
results:
EXPLAIN SELECT table1.id FROM table1,table2 WHERE table1.id = 100 AND table2.id = 100\g
NOTICE: QUERY PLAN:
Nested Loop (cost=4.10 size=2 width=8)
-> Index Scan using table1_idx3 on table1 (cost=2.05 size=1 width=8)
-> Index Scan using table2_idx on table2 (cost=2.05 size=2 width=0)
Which was to be expected, since the 2 indices that are used are on the 'id'
field.
However, when I also get these disappointing results:
EXPLAIN SELECT table1.version FROM table1,table2 WHERE table2.id = table1.id\g
NOTICE: QUERY PLAN:
Hash Join (cost=92.95 size=772 width=16)
-> Seq Scan on table1 (cost=37.44 size=771 width=12)
-> Hash (cost=0.00 size=0 width=0)
-> Seq Scan on table2 (cost=18.03 size=304 width=4)
How come it doesn't use the indices here? Ideas? Is there a better way to do
this?
--
Yes is a BARGAIN
No is a TURNOFF - Wire
--Zachariah - Studio Archetype - 415-659-4435 - mailto:zack@studioarchetype.com
Did you do a VACUUM ANALYZE? Check out man page on: vacuum Zachariah Baum wrote: > I'm running PostgreSQL 6.4 on Linux, and have the following database setup: > > i have 2 tables, table1 and table2, both with an 'id' field, and both with > an index on the 'id' field. > Usually my selects involve a join between the tables, but the join is quite > slow. I played around with the EXPLAIN command, and got the following > results: > > EXPLAIN SELECT table1.id FROM table1,table2 WHERE table1.id = 100 AND table2.id = 100\g > NOTICE: QUERY PLAN: > > Nested Loop (cost=4.10 size=2 width=8) > -> Index Scan using table1_idx3 on table1 (cost=2.05 size=1 width=8) > -> Index Scan using table2_idx on table2 (cost=2.05 size=2 width=0) > > Which was to be expected, since the 2 indices that are used are on the 'id' > field. > > However, when I also get these disappointing results: > EXPLAIN SELECT table1.version FROM table1,table2 WHERE table2.id = table1.id\g > NOTICE: QUERY PLAN: > > Hash Join (cost=92.95 size=772 width=16) > -> Seq Scan on table1 (cost=37.44 size=771 width=12) > -> Hash (cost=0.00 size=0 width=0) > -> Seq Scan on table2 (cost=18.03 size=304 width=4) > > How come it doesn't use the indices here? Ideas? Is there a better way to do > this? > -- > > Yes is a BARGAIN > No is a TURNOFF - Wire > --Zachariah - Studio Archetype - 415-659-4435 - mailto:zack@studioarchetype.com
daveh@insightdist.com said:
> Did you do a VACUUM ANALYZE?
that worked! Thanks a lot.
--
Yes is a BARGAIN
No is a TURNOFF - Wire
--Zachariah - Studio Archetype - 415-659-4435 - mailto:zack@studioarchetype.com