Hyun-Sung,
> do you need all of verbose information??
> VACUUM FULL ANALYZE VERBOSE give me a lot of infomation,
> so i just cut zipcode parts.
Oh, sorry. I meant just "VACUUM FULL ANALYZE VERBOSE zipcode", not the whole
database. Should have been clearer.
> ==start====================================================================
>=========== INFO: vacuuming "public.zipcode"
> INFO: "zipcode": found 0 removable, 47705 nonremovable row versions in
> 572 pages
> DETAIL: 0 dead row versions cannot be removed yet.
OK, looks like you're clean.
> I just choose zipcode table for this test.
> not only zipcode table but other table also give me same result.
>
> SELECT * FROM table_name WHERE PK = 'xxx'
>
> was always slower than
>
> SELECT * FROM table_name WHERE PK = 'xxx' LIMIT 1
>
> when sequence scan .
yeah? So? Stop using sequence scan! You've just demonstrated that, if you
don't force the planner to use sequence scan, things run at the same speed
with or without the LIMIT. So you're causing a problem by forcing the
planner into a bad plan.
See Andrew's explanation of why it works this way.
> ah, why i'm using sequence as PK instead of zip code is
> in korea, the small towns doesn't have it's own zipcode
> so they share other big city's.
> that's why zip code can't be a primary key.
> actually, i'm not using sequence to find zipcode.
> i made it temporary for this test.
That makes sense.
--Josh
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
