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==
On Wed, 2004-12-01 at 15:03 +0900, Hyun-Sung, Jang wrote:
>
> < lots of information about seq scan vs index scan >
>
Hi,
Just because it has an ID that is the largest in the set, does not mean
it will be at the last position in the on-disk tables. And similarly,
the lowest numbered ID does not
do you need all of verbose information??
VACUUM FULL ANALYZE VERBOSE give me a lot of infomation,
so i just cut zipcode parts.
==start===
INFO:Â vacuuming "public.zipcode"
INFO:Â "zipcode": found 0 removable, 47705 non
Hyun-Sang,
> before test, I already executed VACUUM FULL.
> this result show up after vacuum full.
Really? Your results really look like a bloated table. Can you run VACUUM
FULL ANALYZE VERBOSE on the table and post the output?
> When I using index scan, the result was almost same, that mea
before test, I already executed VACUUM FULL.
this result show up after vacuum full.
Tom Lane ì ê:
=?UTF-8?B?7J6l7ZiE7ISx?= <[EMAIL PROTECTED]> writes:
but, sequence scan, as you see above result, there is big time
difference between using LIMIT and without using it.
Y
=?UTF-8?B?7J6l7ZiE7ISx?= <[EMAIL PROTECTED]> writes:
> but, sequence scan, as you see above result, there is big time
> difference between using LIMIT and without using it.
You've got a table full of dead rows. Try VACUUM FULL ...
regards, tom lane
-
hello~
i'm curious about this situation.
here is my test.
my zipcode table has 47705 rows,
and schema looks like this.
pgsql=# \d zipcode
Table "public.zipcode" Column | Type | Modifiers
-+---+--- zipcode | character(7) |
not null sido | character varying(4) |
