weiping <[EMAIL PROTECTED]> writes:
> -> Index Scan using urlusermaps_userid on wd_urlusermaps a
> (cost=0.00..6750.55 rows=1094 width=96) (actual time=0.544..5.616
> rows=41 loops=1)
> Index Cond: (userid = 219177)
> Filter: ("share" = 1)
> the userid=219177 got 2000+ record and around 40 shared=
"weiping" <[EMAIL PROTECTED]> writes:
> -> Index Scan using urlusermaps_userid on wd_urlusermaps
>(cost=0.00..6750.55 rows=1094 width=4) (actual time=1.478..16.563 rows=41
> loops=1)
>Index Cond: (userid = 219177)
>Filter: ("share" = 1)
It's estimating 1094 rows and getting 41 rows.
continue digging shows:
set cpu_tuple_cost to 0.1;
explain analyze select * from wd_urlusermaps where share =1 and
userid='219177' order by id desc limit 20;
SET
时间: 0.256 ms
QUERY PLAN
-
I changed the query to :
EXPLAIN ANALYZE select id from wd_urlusermaps where id in (select id
from wd_urlusermaps where share =1 and userid='219177') order by id desc
limit 20;
and it's much better now (from real execute time), but the cost report
higher
then slower one above, may be I should do s
sorry, forgot to mention our version, it's postgresql 8.2.3
-laser
> I have a table:
> webdigest=# \d wd_urlusermaps
> 表 "public.wd_urlusermaps"
> 字段名 | 类型 | 修饰词
> -+-+-
> id | integer | not null defaul
I have a table:
webdigest=# \d wd_urlusermaps
表 "public.wd_urlusermaps"
字段名 | 类型 | 修饰词
-+-+-
id | integer | not null default nextval('wd_urlusermaps_id_seq'::regclass)
urlid | integer | not null
tag | ch
