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

От: Jean-Michel Pouré
Тема: Re: PostgreSQL does CAST implicitely between int and adomain derived from int
Дата: ,
Msg-id: 1251383862.13130.1.camel@acer
(см: обсуждение, исходный текст)
Ответ на: Re: PostgreSQL does CAST implicitely between int and adomain derived from int  ("Kevin Grittner")
Ответы: Re: PostgreSQL does CAST implicitely between int andadomain derived from int  ("Kevin Grittner")
Список: pgsql-performance

Скрыть дерево обсуждения

Re: PostgreSQL does CAST implicitely between int and a domain derived from int  ("Kevin Grittner", )
 Re: PostgreSQL does CAST implicitely between int and a domain derived from int  ("Kevin Grittner", )
  Re: PostgreSQL does CAST implicitely between int and a domain derived from int  (Jean-Michel Pouré, )
   Re: PostgreSQL does CAST implicitely between int and adomain derived from int  ("Kevin Grittner", )
    Re: PostgreSQL does CAST implicitely between int and adomain derived from int  (Jean-Michel Pouré, )
     Re: PostgreSQL does CAST implicitely between int andadomain derived from int  ("Kevin Grittner", )
      Re: PostgreSQL does CAST implicitely between int andadomain derived from int  (Jean-Michel Pouré, )
       Re: PostgreSQL does CAST implicitely between int and a domain derived from int  ("Kevin Grittner", )
        Re: PostgreSQL  (Jean-Michel Pouré, )
        Re: PostgreSQL does CAST implicitely between int and a domain derived from int  (Robert Haas, )
         Re: PostgreSQL does CAST implicitely between int and a domain derived from int  (Tom Lane, )
          Re: PostgreSQL does CAST implicitely between int and a domain derived from int  (Jean-Michel Pouré, )
           Re: PostgreSQL does CAST implicitely between int and a domain derived from int  (Bruce Momjian, )
            Re: PostgreSQL does CAST implicitely between int and a domain derived from int  (Jean-Michel Pouré, )
             Re: PostgreSQL does CAST implicitely between int and a domain derived from int  (Tom Lane, )
              Re: PostgreSQL does CAST implicitely between int and a domain derived from int  (Jean-Michel Pouré, )
               Re: PostgreSQL does CAST implicitely between int and a domain derived from int  (Tom Lane, )
                Re: PostgreSQL does CAST implicitely between int and a domain derived from int  (Greg Stark, )
         Re: PostgreSQL does CAST implicitely between int and a domain derived from int  (Jean-Michel Pouré, )
 Re: PostgreSQL does CAST implicitely between int and a domain derived from int  (Jean-Michel Pouré, )
  Re: PostgreSQL does CAST implicitely between int and adomain derived from int  ("Kevin Grittner", )
   Re: PostgreSQL does CAST implicitely between int and adomain derived from int  (Jean-Michel Pouré, )

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

Вложения

В списке pgsql-performance по дате сообщения:

От: gael@pilotsystems.net (Gaël Le Mignot)
Дата:
Сообщение: Re: Performance regression between 8.3 and 8.4 on heavy text indexing
От: Guillaume Smet
Дата:
Сообщение: Re: Performance regression between 8.3 and 8.4 on heavy text indexing