Unix Technical Forum

Forcing index usage without 'enable_hashjoin = FALSE'

This is a discussion on Forcing index usage without 'enable_hashjoin = FALSE' within the Pgsql Performance forums, part of the PostgreSQL category; --> I'm using PostgreSQL 8.1.4 and I'm trying to force the planner to use an index. With the index, I ...


Go Back   Unix Technical Forum > Database Server Software > PostgreSQL > Pgsql Performance

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 04-19-2008, 09:17 AM
Dan Langille
 
Posts: n/a
Default Forcing index usage without 'enable_hashjoin = FALSE'

I'm using PostgreSQL 8.1.4 and I'm trying to force the planner to use
an index. With the index, I get executions times of 0.5 seconds.
Without, it's closer to 2.5 seconds.

Compare these two sets of results (also provided at
http://rafb.net/paste/results/ywcOZP66.html
should it appear poorly formatted below):

freshports.org=# \i test2.sql

QUERY PLAN
----------------------------------------------------------------------
----------------------------------------------------------------------
-
Merge Join (cost=24030.39..24091.43 rows=3028 width=206) (actual
time=301.301..355.261 rows=3149 loops=1)
Merge Cond: ("outer".id = "inner".category_id)
-> Sort (cost=11.17..11.41 rows=97 width=4) (actual
time=0.954..1.300 rows=95 loops=1)
Sort Key: c.id
-> Seq Scan on categories c (cost=0.00..7.97 rows=97
width=4) (actual time=0.092..0.517 rows=97 loops=1)
-> Sort (cost=24019.22..24026.79 rows=3028 width=206) (actual
time=300.317..314.114 rows=3149 loops=1)
Sort Key: p.category_id
-> Nested Loop (cost=0.00..23844.14 rows=3028 width=206)
(actual time=0.082..264.459 rows=3149 loops=1)
-> Seq Scan on ports p (cost=0.00..6141.11 rows=3028
width=206) (actual time=0.026..133.575 rows=3149 loops=1)
Filter: (status = 'D'::bpchar)
-> Index Scan using element_pkey on element e
(cost=0.00..5.83 rows=1 width=4) (actual time=0.022..0.026 rows=1
loops=3149)
Index Cond: ("outer".element_id = e.id)
Total runtime: 369.869 ms
(13 rows)

freshports.org=# set enable_hashjoin = true;
SET
freshports.org=# \i test2.sql
QUERY PLAN
----------------------------------------------------------------------
----------------------------------------------------------
Hash Join (cost=6156.90..13541.14 rows=3028 width=206) (actual
time=154.741..2334.366 rows=3149 loops=1)
Hash Cond: ("outer".category_id = "inner".id)
-> Hash Join (cost=6148.68..13472.36 rows=3028 width=206)
(actual time=153.801..2288.792 rows=3149 loops=1)
Hash Cond: ("outer".id = "inner".element_id)
-> Seq Scan on element e (cost=0.00..4766.70 rows=252670
width=4) (actual time=0.022..1062.626 rows=252670 loops=1)
-> Hash (cost=6141.11..6141.11 rows=3028 width=206)
(actual time=151.105..151.105 rows=3149 loops=1)
-> Seq Scan on ports p (cost=0.00..6141.11 rows=3028
width=206) (actual time=0.027..131.072 rows=3149 loops=1)
Filter: (status = 'D'::bpchar)
-> Hash (cost=7.97..7.97 rows=97 width=4) (actual
time=0.885..0.885 rows=97 loops=1)
-> Seq Scan on categories c (cost=0.00..7.97 rows=97
width=4) (actual time=0.076..0.476 rows=97 loops=1)
Total runtime: 2346.877 ms
(11 rows)

freshports.org=#

Without leaving "enable_hashjoin = false", can you suggest a way to
force the index usage?

FYI, the query is:

explain analyse
SELECT P.id,
P.category_id,
P.version as version,
P.revision as revision,
P.element_id,
P.maintainer,
P.short_description,
to_char(P.date_added - SystemTimeAdjust(), 'DD Mon YYYY
HH24:MI:SS') as date_added,
P.last_commit_id as last_change_log_id,
P.package_exists,
P.extract_suffix,
P.homepage,
P.status,
P.broken,
P.forbidden,
P.ignore,
P.restricted,
P.deprecated,
P.no_cdrom,
P.expiration_date,
P.latest_link
FROM categories C, ports P JOIN element E on P.element_id = E.id
WHERE P.status = 'D'
AND P.category_id = C.id;

--
Dan Langille : Software Developer looking for work
my resume: http://www.freebsddiary.org/dan_langille.php



---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #2 (permalink)  
Old 04-19-2008, 09:18 AM
Chris
 
Posts: n/a
Default Re: Forcing index usage without 'enable_hashjoin = FALSE'

Dan Langille wrote:
> I'm using PostgreSQL 8.1.4 and I'm trying to force the planner to use
> an index. With the index, I get executions times of 0.5 seconds.
> Without, it's closer to 2.5 seconds.
>
> Compare these two sets of results (also provided at
> http://rafb.net/paste/results/ywcOZP66.html
> should it appear poorly formatted below):
>
> freshports.org=# \i test2.sql
>
> QUERY PLAN
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> -
> Merge Join (cost=24030.39..24091.43 rows=3028 width=206) (actual
> time=301.301..355.261 rows=3149 loops=1)
> Merge Cond: ("outer".id = "inner".category_id)
> -> Sort (cost=11.17..11.41 rows=97 width=4) (actual
> time=0.954..1.300 rows=95 loops=1)
> Sort Key: c.id
> -> Seq Scan on categories c (cost=0.00..7.97 rows=97
> width=4) (actual time=0.092..0.517 rows=97 loops=1)
> -> Sort (cost=24019.22..24026.79 rows=3028 width=206) (actual
> time=300.317..314.114 rows=3149 loops=1)
> Sort Key: p.category_id
> -> Nested Loop (cost=0.00..23844.14 rows=3028 width=206)
> (actual time=0.082..264.459 rows=3149 loops=1)
> -> Seq Scan on ports p (cost=0.00..6141.11 rows=3028
> width=206) (actual time=0.026..133.575 rows=3149 loops=1)
> Filter: (status = 'D'::bpchar)
> -> Index Scan using element_pkey on element e
> (cost=0.00..5.83 rows=1 width=4) (actual time=0.022..0.026 rows=1
> loops=3149)
> Index Cond: ("outer".element_id = e.id)
> Total runtime: 369.869 ms
> (13 rows)
>
> freshports.org=# set enable_hashjoin = true;
> SET
> freshports.org=# \i test2.sql
> QUERY PLAN
> ----------------------------------------------------------------------
> ----------------------------------------------------------
> Hash Join (cost=6156.90..13541.14 rows=3028 width=206) (actual
> time=154.741..2334.366 rows=3149 loops=1)
> Hash Cond: ("outer".category_id = "inner".id)
> -> Hash Join (cost=6148.68..13472.36 rows=3028 width=206)
> (actual time=153.801..2288.792 rows=3149 loops=1)
> Hash Cond: ("outer".id = "inner".element_id)
> -> Seq Scan on element e (cost=0.00..4766.70 rows=252670
> width=4) (actual time=0.022..1062.626 rows=252670 loops=1)
> -> Hash (cost=6141.11..6141.11 rows=3028 width=206)
> (actual time=151.105..151.105 rows=3149 loops=1)
> -> Seq Scan on ports p (cost=0.00..6141.11 rows=3028
> width=206) (actual time=0.027..131.072 rows=3149 loops=1)
> Filter: (status = 'D'::bpchar)
> -> Hash (cost=7.97..7.97 rows=97 width=4) (actual
> time=0.885..0.885 rows=97 loops=1)
> -> Seq Scan on categories c (cost=0.00..7.97 rows=97
> width=4) (actual time=0.076..0.476 rows=97 loops=1)
> Total runtime: 2346.877 ms
> (11 rows)
>
> freshports.org=#
>
> Without leaving "enable_hashjoin = false", can you suggest a way to
> force the index usage?
>
> FYI, the query is:
>
> explain analyse
> SELECT P.id,
> P.category_id,
> P.version as version,
> P.revision as revision,
> P.element_id,
> P.maintainer,
> P.short_description,
> to_char(P.date_added - SystemTimeAdjust(), 'DD Mon YYYY
> HH24:MI:SS') as date_added,
> P.last_commit_id as last_change_log_id,
> P.package_exists,
> P.extract_suffix,
> P.homepage,
> P.status,
> P.broken,
> P.forbidden,
> P.ignore,
> P.restricted,
> P.deprecated,
> P.no_cdrom,
> P.expiration_date,
> P.latest_link
> FROM categories C, ports P JOIN element E on P.element_id = E.id
> WHERE P.status = 'D'
> AND P.category_id = C.id;
>


I doubt it would make a difference but if you:

....
FROM categories C JOIN ports P on P.category_id=C.id JOIN element E on
P.element_id = E.id
WHERE P.status = 'D';

does it change anything?

--
Postgresql & php tutorials
http://www.designmagick.com/

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #3 (permalink)  
Old 04-19-2008, 09:18 AM
Dan Langille
 
Posts: n/a
Default Re: Forcing index usage without 'enable_hashjoin = FALSE'

On 23 Aug 2006 at 13:31, Chris wrote:

> Dan Langille wrote:
> > I'm using PostgreSQL 8.1.4 and I'm trying to force the planner to use
> > an index. With the index, I get executions times of 0.5 seconds.
> > Without, it's closer to 2.5 seconds.
> >
> > Compare these two sets of results (also provided at
> > http://rafb.net/paste/results/ywcOZP66.html
> > should it appear poorly formatted below):
> >
> > freshports.org=# \i test2.sql
> >
> > QUERY PLAN
> > ----------------------------------------------------------------------
> > ----------------------------------------------------------------------
> > -
> > Merge Join (cost=24030.39..24091.43 rows=3028 width=206) (actual
> > time=301.301..355.261 rows=3149 loops=1)
> > Merge Cond: ("outer".id = "inner".category_id)
> > -> Sort (cost=11.17..11.41 rows=97 width=4) (actual
> > time=0.954..1.300 rows=95 loops=1)
> > Sort Key: c.id
> > -> Seq Scan on categories c (cost=0.00..7.97 rows=97
> > width=4) (actual time=0.092..0.517 rows=97 loops=1)
> > -> Sort (cost=24019.22..24026.79 rows=3028 width=206) (actual
> > time=300.317..314.114 rows=3149 loops=1)
> > Sort Key: p.category_id
> > -> Nested Loop (cost=0.00..23844.14 rows=3028 width=206)
> > (actual time=0.082..264.459 rows=3149 loops=1)
> > -> Seq Scan on ports p (cost=0.00..6141.11 rows=3028
> > width=206) (actual time=0.026..133.575 rows=3149 loops=1)
> > Filter: (status = 'D'::bpchar)
> > -> Index Scan using element_pkey on element e
> > (cost=0.00..5.83 rows=1 width=4) (actual time=0.022..0.026 rows=1
> > loops=3149)
> > Index Cond: ("outer".element_id = e.id)
> > Total runtime: 369.869 ms
> > (13 rows)
> >
> > freshports.org=# set enable_hashjoin = true;
> > SET
> > freshports.org=# \i test2.sql
> > QUERY PLAN
> > ----------------------------------------------------------------------
> > ----------------------------------------------------------
> > Hash Join (cost=6156.90..13541.14 rows=3028 width=206) (actual
> > time=154.741..2334.366 rows=3149 loops=1)
> > Hash Cond: ("outer".category_id = "inner".id)
> > -> Hash Join (cost=6148.68..13472.36 rows=3028 width=206)
> > (actual time=153.801..2288.792 rows=3149 loops=1)
> > Hash Cond: ("outer".id = "inner".element_id)
> > -> Seq Scan on element e (cost=0.00..4766.70 rows=252670
> > width=4) (actual time=0.022..1062.626 rows=252670 loops=1)
> > -> Hash (cost=6141.11..6141.11 rows=3028 width=206)
> > (actual time=151.105..151.105 rows=3149 loops=1)
> > -> Seq Scan on ports p (cost=0.00..6141.11 rows=3028
> > width=206) (actual time=0.027..131.072 rows=3149 loops=1)
> > Filter: (status = 'D'::bpchar)
> > -> Hash (cost=7.97..7.97 rows=97 width=4) (actual
> > time=0.885..0.885 rows=97 loops=1)
> > -> Seq Scan on categories c (cost=0.00..7.97 rows=97
> > width=4) (actual time=0.076..0.476 rows=97 loops=1)
> > Total runtime: 2346.877 ms
> > (11 rows)
> >
> > freshports.org=#
> >
> > Without leaving "enable_hashjoin = false", can you suggest a way to
> > force the index usage?
> >
> > FYI, the query is:
> >
> > explain analyse
> > SELECT P.id,
> > P.category_id,
> > P.version as version,
> > P.revision as revision,
> > P.element_id,
> > P.maintainer,
> > P.short_description,
> > to_char(P.date_added - SystemTimeAdjust(), 'DD Mon YYYY
> > HH24:MI:SS') as date_added,
> > P.last_commit_id as last_change_log_id,
> > P.package_exists,
> > P.extract_suffix,
> > P.homepage,
> > P.status,
> > P.broken,
> > P.forbidden,
> > P.ignore,
> > P.restricted,
> > P.deprecated,
> > P.no_cdrom,
> > P.expiration_date,
> > P.latest_link
> > FROM categories C, ports P JOIN element E on P.element_id = E.id
> > WHERE P.status = 'D'
> > AND P.category_id = C.id;
> >

>
> I doubt it would make a difference but if you:
>
> ...
> FROM categories C JOIN ports P on P.category_id=C.id JOIN element E on
> P.element_id = E.id
> WHERE P.status = 'D';
>
> does it change anything?


Not really, no:

freshports.org=# \i test3.sql

QUERY PLAN
----------------------------------------------------------------------
----------------------------------------------------------------------
---
Hash Join (cost=5344.62..12740.73 rows=3365 width=204) (actual
time=63.871..2164.880 rows=3149 loops=1)
Hash Cond: ("outer".category_id = "inner".id)
-> Hash Join (cost=5336.41..12665.22 rows=3365 width=204)
(actual time=62.918..2122.529 rows=3149 loops=1)
Hash Cond: ("outer".id = "inner".element_id)
-> Seq Scan on element e (cost=0.00..4767.58 rows=252758
width=4) (actual time=0.019..1024.299 rows=252791 loops=1)
-> Hash (cost=5328.00..5328.00 rows=3365 width=204)
(actual time=60.228..60.228 rows=3149 loops=1)
-> Bitmap Heap Scan on ports p (cost=34.02..5328.00
rows=3365 width=204) (actual time=1.900..41.316 rows=3149 loops=1)
Recheck Cond: (status = 'D'::bpchar)
-> Bitmap Index Scan on ports_deleted
(cost=0.00..34.02 rows=3365 width=0) (actual time=1.454..1.454
rows=3149 loops=1)
Index Cond: (status = 'D'::bpchar)
-> Hash (cost=7.97..7.97 rows=97 width=4) (actual
time=0.890..0.890 rows=97 loops=1)
-> Seq Scan on categories c (cost=0.00..7.97 rows=97
width=4) (actual time=0.074..0.497 rows=97 loops=1)
Total runtime: 2176.784 ms
(13 rows)

freshports.org=#



--
Dan Langille : Software Developer looking for work
my resume: http://www.freebsddiary.org/dan_langille.php



---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #4 (permalink)  
Old 04-19-2008, 09:18 AM
Tom Lane
 
Posts: n/a
Default Re: Forcing index usage without 'enable_hashjoin = FALSE'

"Dan Langille" <dan@langille.org> writes:
> Without leaving "enable_hashjoin = false", can you suggest a way to
> force the index usage?


Have you tried reducing random_page_cost?

FYI, 8.2 should be a bit better about this.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #5 (permalink)  
Old 04-19-2008, 09:18 AM
Dan Langille
 
Posts: n/a
Default Re: Forcing index usage without 'enable_hashjoin = FALSE'

On 23 Aug 2006 at 22:30, Tom Lane wrote:

> "Dan Langille" <dan@langille.org> writes:
> > Without leaving "enable_hashjoin = false", can you suggest a way to
> > force the index usage?

>
> Have you tried reducing random_page_cost?


Yes. No effect.

> FYI, 8.2 should be a bit better about this.


Good. This query is not critical, but it would be nice.

Thank you.

--
Dan Langille : Software Developer looking for work
my resume: http://www.freebsddiary.org/dan_langille.php



---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On
Forum Jump


All times are GMT. The time now is 04:10 AM.


Powered by vBulletin® Version 3.6.5
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Search Engine Optimization by vBSEO 3.2.0
www.UnixAdminTalk.com