Re: PostgreSQL does CAST implicitely between int and adomain derived from int

From: Jean-Michel Pouré <jm(at)poure(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: PostgreSQL does CAST implicitely between int and adomain derived from int
Date: 2009-08-27 14:37:42
Message-ID: 1251383862.13130.1.camel@acer
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Le jeudi 27 août 2009 à 09:16 -0500, Kevin Grittner a écrit :
> Then you need to use a better tool to run it.

Understood, thanks.

cms=# set work_mem = '50MB';
SET
cms=# set effective_cache_size = '1GB';
SET
cms=# begin transaction;
BEGIN
cms=# drop index node_comment_statistics_node_comment_timestamp_idx;
DROP INDEX
cms=#
cms=# EXPLAIN ANALYSE
cms-# SELECT ncs.last_comment_timestamp, IF (ncs.last_comment_uid != 0,
u2.name, ncs.last_comment_name) AS last_comment_name,
ncs.last_comment_uid
cms-# FROM node n
cms-# INNER JOIN users u1 ON n.uid = u1.uid
cms-# INNER JOIN term_node tn ON n.vid = tn.vid
cms-# INNER JOIN node_comment_statistics ncs ON n.nid = ncs.nid
cms-# INNER JOIN users u2 ON ncs.last_comment_uid=u2.uid
cms-# WHERE n.status = 1 AND tn.tid = 3
cms-# ORDER BY ncs.last_comment_timestamp DESC LIMIT 1 OFFSET 0 ;
cms=# rollback transaction;

QUERY
PLAN
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=972.82..972.82 rows=1 width=17) (actual time=0.018..0.018
rows=0 loops=1)
-> Sort (cost=972.82..973.04 rows=91 width=17) (actual
time=0.018..0.018 rows=0 loops=1)
Sort Key: ncs.last_comment_timestamp
Sort Method: quicksort Memory: 25kB
-> Nested Loop (cost=4.96..972.36 rows=91 width=17) (actual
time=0.010..0.010 rows=0 loops=1)
-> Nested Loop (cost=4.96..945.74 rows=91 width=21)
(actual time=0.010..0.010 rows=0 loops=1)
-> Nested Loop (cost=4.96..919.34 rows=91
width=13) (actual time=0.010..0.010 rows=0 loops=1)
-> Nested Loop (cost=4.96..890.02 rows=91
width=8) (actual time=0.009..0.009 rows=0 loops=1)
-> Bitmap Heap Scan on term_node tn
(cost=4.96..215.63 rows=91 width=4) (actual time=0.009..0.009 rows=0
loops=1)
Recheck Cond: ((tid)::integer =
3)
-> Bitmap Index Scan on
term_node_tid_idx (cost=0.00..4.94 rows=91 width=0) (actual
time=0.008..0.008 rows=0 loops=1)
Index Cond: ((tid)::integer
= 3)
-> Index Scan using node_vid_idx on
node n (cost=0.00..7.40 rows=1 width=12) (never executed)
Index Cond: ((n.vid)::integer =
(tn.vid)::integer)
Filter: (n.status = 1)
-> Index Scan using
node_comment_statistics_pkey on node_comment_statistics ncs
(cost=0.00..0.31 rows=1 width=13) (never executed)
Index Cond: ((ncs.nid)::integer =
n.nid)
-> Index Scan using users_pkey on users u2
(cost=0.00..0.28 rows=1 width=12) (never executed)
Index Cond: (u2.uid = ncs.last_comment_uid)
-> Index Scan using users_pkey on users u1
(cost=0.00..0.28 rows=1 width=4) (never executed)
Index Cond: (u1.uid = n.uid)
Total runtime: 0.092 ms
(22 lignes)

Does it mean my index is broken and should be rebuilt?

Kind regards,
Jean-Michel

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Kevin Grittner 2009-08-27 14:52:28 Re: PostgreSQL does CAST implicitely between int andadomain derived from int
Previous Message Kevin Grittner 2009-08-27 14:16:17 Re: PostgreSQL does CAST implicitely between int and adomain derived from int