I have a small table that has 23 rows only, but I do updates on the
table every second. After running the updates for a while, the
performance on SELECT from the table deteriates so much.

The followings are some stats:

Test=> VACUUM VERBOSE analyze schedule ;
INFO: vacuuming "public.schedule"
INFO: index "schedule_pkey" now contains 23 row versions in 2519 pages
DETAIL: 2499 index pages have been deleted, 2499 are currently
reusable.
CPU 0.27s/0.04u sec elapsed 12.49 sec.
INFO: "schedule": found 0 removable, 23 nonremovable row versions in
37638 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 974282 unused item pointers.
0 pages are entirely empty.
CPU 3.64s/0.48u sec elapsed 76.15 sec.
INFO: vacuuming "pg_toast.pg_toast_22460"
INFO: index "pg_toast_22460_index" now contains 0 row versions in 1
pages
DETAIL: 0 index pages have been deleted, 0 are currently reusable.
CPU 0.01s/0.00u sec elapsed 0.03 sec.
INFO: "pg_toast_22460": found 0 removable, 0 nonremovable row versions
in 0 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 0 unused item pointers.
0 pages are entirely empty.
CPU 0.01s/0.00u sec elapsed 0.03 sec.
INFO: analyzing "public.schedule"
INFO: "schedule": 37638 pages, 23 rows sampled, 23 estimated total
rows
VACUUM

If I do an explain:

Test=> explain select id from schedule;
QUERY PLAN
-------------------------------------------------------------
Seq Scan on schedule (cost=0.00..37638.23 rows=23 width=4)
(1 row)

I suspect the reason the select is taking way too long is because the
sequential scan needs to scan over 37638 tuples?

How can I force it to shrink to a more reasonable number WITHOUT doing
a VACUUM FULL?

Thanks!